3Duck is a Forth interpreter married to SDL with OpenGL binding. It's based on Richard Jones' excellent tutorial (Not sure of implementation's excellence... I'm rather new to forth and my assembly skill is rather green) jonesforth written in x86 assembler. Hopefully it'll prove to be an adequite platform for 3D engine experimentation.
After playing with gdb a bit, I found SDL was requesting memory I thought it would avoid. Having not found any info on cooperating with malloc, I rewrote the memory handling in jonesforth to use malloc instead.
Ultimately, I think this is the right thing to do because I'll be needing to request chunks of memory to pass to GL functions, which will need to be free()'d.
There's just no info out there on getting assembly apps to play nice with libraries. I play with it for a few minutes, get frustrated, and play WoW for a few hours. Not exactly condusive to progress but considering my level of discontent and frustration in my life in general, I don't much care.
Good thing I'm not on a deadline. ;)
Something's not playing nice. After I call SDL_SetVideoMode I lose my dictionary. My guess is that SDL is overwriting my memory. Time to figure out what malloc is doing and accomodate for it.
I love this code! I've wanted to learn x86 for a while, but never found examples of from-scratch code with enough context. Having a 6502 background, I know general assembly basics, so running across Richard's article on LtU (via reddit) was like a gift from the gods.
Adding some basic SDL constants and a CALL word was pretty straight forward. The C calling convention looks kinda ugly paired up with Forth. At least as I've done it: you push your args onto the stack in reverse order, push the function word, run CALL and it replaces the last arg (the function location) with the result - it's then up to you to clean up the stack since the calling convention states that that's left up to the caller. But I suppose wrapper words would pretty it up.