Not logged in, Join Here! or Log In Below:  
News Articles Search    

Submitted by Alexander Herz, posted on February 11, 2001

Image Description, by Alexander Herz

I thought I'd contribute this in contrast to all the rendering stuff seen as IOTD mostly.. The pic shows a shot of my IDE which is used to created and debug scripts using my ScriptC compiler. The scripts are run on my Virtual Machine which is integrated in my actual engine called 'Q'.

You have most of the features I considered nice in debugging in c code, Reg and Mem view, variable watch etc..

You can download the IDE together with all tools and stuff needed to execute/debug on my homepage at in the news section (window at the bottom) there's a link to the files(zipped).

Debugging asm code is soon to come...

Alex Herz

Image of the Day Gallery


Message Center / Reader Comments: ( To Participate in the Discussion, Join the Community )
Archive Notice: This thread is old and no longer active. It is here for reference purposes. This thread was created on an older version of the flipcode forums, before the site closed in 2005. Please keep that in mind as you view this thread, as many of the topics and opinions may be outdated.

February 11, 2001, 11:55 AM

Hey i like that...
Especially the bumpmapping-efects are very cool!
is it opengl or direct3d ? ;-)


February 11, 2001, 01:00 PM

Hex code and text boxes and menus, oh my! Looks very nice. I've never attempted to write a script compiler, but it looks difficult. I'll probably try it after the next "Game Programming Genesis" article on What are your scripts used for?


February 11, 2001, 02:19 PM

Kewl. If you like this, take a look at a similar IOTD from Jan 2000.

Nice work.

Alex Herz

February 11, 2001, 02:45 PM

Your *old* IOTD looks realy cool..

I'd be interested to hear a bit more about your vm...
What format has your binary pseudo asm?

Can I get what you can see on that shot somewhere?

Do you use internal structures which are equally to their c/c++ partners or does vm manage all that?

Can you debug your scripts?

How does the VM link in external funcs(such placed in dlls and so on)

and most do you color your code?
My approach is a bad hack ..ok..the complete app rather is a bad hack..5k win32 code without MFC or anything..


Alex Herz

February 11, 2001, 02:58 PM

Yet my engine is a bunch of modules (one of em is the VM) run by a server which handles net/gfx/what ever...
It can be used for any kind of game.
I doesn't even have a 3d engine yet, just some tests I did for bezier patches and some landscape stuff..
So there is no special purpose for scripts yet but they are intended to be used by level designers later who can script motions/particle systems/monster ai/what ever ..

The server gives you (via script) access to all internal objecs and stuff. You could script an automatic network game creation, random level selection hu what ever you can do anything you could
do as a 'normal' client of the server with normal intel code..


Alex Herz

February 11, 2001, 03:00 PM

My engine runs ontop of ogl infact..but it is run in 'silent' mode
on this shot as it would cover big parts of the screen otherwise...
Though it uses directx for sound and networking..



February 11, 2001, 03:09 PM

Looks like these guys seriously ripped off Microsoft Developer Studio


February 11, 2001, 04:29 PM

Alex, thanks for sharing your work with the rest of the community; I appreciate it, plus Im confident others do too. For those who like to say your program looks like you ripped off some other package, take it as a compliment worded awkwardly :) Seriously though, it shows that your user interface operates in a consistent manner, thereby making it easier to use. Other projects from your website also shows that you know how to do non-standard things as well. I'm curious as to whether you used MFC with your application, or if you used straight WIN32 API.

- Shriek

Mark Friedenbach

February 11, 2001, 04:30 PM

And why not? Better to provide a familiar environment, than a new awkward one that would take weeks to get used to.

Alex Herz

February 11, 2001, 04:49 PM almost all stuff I wrote about this IDE Inoted that it is derivered from the MSVC I forgot this sorry..
but it's obvious anyways..

MSVC is the best tool I found for coding so this is kinda my tribute..I don't realy know how to do better..apart from some details..and I added these details to my app...

normally I'm no M$ fan though..

and normally I take pretty non standart approaches..


Alex Herz

February 11, 2001, 04:59 PM


I didn't use MFC, it's plain Win32.
ANd it was of course derivered from MSVC's interface..forgot to mention's the best interface I know for coding..
But I added/changed some details I dislike in MSVC..
The basic part of it is a richedit control...
I added some routine to color the code..but it's pretty much a hack..
same applyes to the debugging..
I heavily use OutputDebugString in my Virtual machine to send the adresses of importand items in the vm to the IDE..then I use Read/WriteProcessMemory to communicate with the VM..
(set breakpoints, read/write registers etc)

My compile translates the c sources into intel similar asm code which is binary encoded (each symbol like 'mov' 'jmp',... has a nique id..
I wrote much about that on my homepage and in my techfile here..

the Vm loads the script, links missing funcs and parses the binary asm code..

I had plans to make the vm realy fast..would have been 6-12 times slower than cpu..but it would have been hell a lot of pretty boring work..that way with the parsing it makes 7.5 mio asm commands/sec on a PIII 700..not too fast..but you can call (and runtime link) dll funcs


Navreet Gill

February 11, 2001, 09:55 PM

Nice work!

this is a little off the subject, but does anyone know a nice Assembly IDE that I could get for free? over the internet perhaps?



February 12, 2001, 12:15 AM

OutputDebugString("test shit");



February 12, 2001, 06:45 AM

you can use MSDev for that, just create a Makefile ...

or, if you use NASM, you could also use NASM-Ide :


February 12, 2001, 08:04 AM

This looks great man ;)


February 12, 2001, 08:29 AM


I wrote a script interpreter for my final year project at uni. It didn't have all this though!

How do you do the debugging? I.e. Step through the script as it executes? You mentioned Read/WriteProcessMemory. What do they do?

I thought I was hot shit allowing calls to external DLLs. Haha. Everyone does it now.

Oh yeah, my IDE looked almost identical to this IOTD which was mentioned earlier. I used a library called the Business Component Library. Basically, this library is a bunch of MFC code that gives you cool everything! Win2000 style menus, docking windows, customisable everything the whole nine yards. Best of all, its free and there is no charge for putting it in your Comercial app.

You can read more about it here

Good work.


Alex Herz

February 12, 2001, 08:50 AM

hm..I gotta look at that library..cause doung all the docking MDI what ever stuff which is common in these kinda apps by hand is realy much work and not realy worth's just I dislike MFC :)

deugging works pretty easy..

The IDE opens an new process(CreateProcess) which runs the VirtualMachine using the debug flag (one of the flags passed to CreateProcess)

then you have an infinite loop which waits for debugging events send by the vm(the system automatically sends these to the IDE as we set the debug flag) soon a debug event occurs(maybe a runtime error or a string was send using OutputDebugString) the process (VM) is suspended and the IDE get's control(also happens automatically)..
now the IDE can react to the debug event and have the VM continue running to the next debug event..

The IDE parses the debug strings send from VM to IDE via OutputDebugString ...most of em specify adresses of structures
the IDE needs to use for debugging..for example one of the strings is:
"BreakPointArray: 0x0024ba23" ...that's the relative adress of an array of DWORDs where each DWORD specifies a line where the VM should break and assign control back to IDE (cause a breakpoint was reached)..but as the adress is relative to the VM's procces's offset
you cannot access it directely like this
*((DWORD*)0x0024ba23)=3;//break at line 3
To write into the mem of another process you use Read/WriteProcessMemory..and use 0x0024ba23 as BaseAdress (in this case)..

now every cycle of the vm(each time it completed executing an asm command) it compares the line info saved in the binarys(debug compilation of the scripts only)..if it is equal to one of the numbers written to the BreakPointArray then it Sends another message to the IDE again via OutputDebugString.which looks somewhat like this:
"BreakPoint: 9,2" where 9 is the line number and 2 is the id of a sourcefile..(you can compile multiple sources into one output binary)
If the IDE gets that message it loads the corresponding file and sets the yellow arrow to the line indicated..

For step execution you simply set a breakpoint at each line..

To allow variables watch the compiler adds info about all variables(next to th linker stuff) at the end of the binaries..which save var names, types and offset..



February 12, 2001, 09:06 AM

Nice, I never got round to doing a proper binary output for a VM, all the stubs for the output were there, they just had nothing in them. I went with a self executing parse tree instead becasue it was quicker to implement.

Are you doing all the parsing yourself or do you use flex/bison?
One sugestion I would make is automatically having a "Soft Break Point" defined for every valid source line. The real breakpoint or "Hard Break Point" would cause the code to pop up in the IDE, a soft one does not, they are simply to tell the IDE that another source line has been reached. The VM should send its debugging info for each "Soft Break Point" but the IDE will ignore them unless is is currently stepping through after finding a "Hard Break Point". Wow, thats a long sentence!


This thread contains 18 messages.
Hosting by Solid Eight Studios, maker of PhotoTangler Collage Maker.