SpritesMind.Net

Thanks
Yes I started with basic 2D sinus effects then I saw your cube rolling at decent fps which gived hopes !
Thanks for this fantastic SDK !!!

Thanks :p
If i find sometime, i would like to complete the BMP_FF_xx stuff to make a starfox like demo (3D flat) on stock megadrive. I think that if we could not get exactly starfox, we can have something not that far... and without extra hardware

This has already been done long ago.

Shiru wrote:This has already been done long ago.

Yeah i know about this (unreleased) game =) this is the bonus part if i remember correctly... It is really impressive so far and i would like to do something similar... in better (if that's possible) :p

Starfox on SNES is mostly 10fps or so on real hardware, it is really choppy. I don't think you don't need to try too hard to create a game that is comparable and perhaps even exceed Starfox on MD. The more you try the better though

yeah i know that starfox on the real hardware is choppy and barely at 10/12 FPS (emulator generally gives better frame rate). Anyway even 10 FPS, with the number of triangles and the rendering, this is a big challenge for the megadrive

With low framerate it is still possible to make a 3D adventure like Total Eclipse.

Hehe it looks a bit choppy and window size is really small, but at least, that is full 3D (starfox is more limited as world is only translated).

Me again I'm having some issues using timer functions. Seems waitMs() and waitTick() completly hangs execution in SGDK 0.91

Moon-Watcher wrote:Me again I'm having some issues using timer functions. Seems waitMs() and waitTick() completly hangs execution in SGDK 0.91

Ah yeah i forgot to fix that problem... for the moment you can't call these methods from your V interrupt callback else you lock the program :-/

Stef wrote:

Moon-Watcher wrote:Me again I'm having some issues using timer functions. Seems waitMs() and waitTick() completly hangs execution in SGDK 0.91

Ah yeah i forgot to fix that problem... for the moment you can't call these methods from your V interrupt callback else you lock the program :-/

Interrupt driven callbacks should NEVER use delays (other than small CPU loops for something like reading controllers) as you want to handle the event and exit using as little time as possible.

For things that NEED some kind of long delay, you probably want a deferred task - as an int is exited, it checks for a deferred task, and runs it at normal level like the code that was running before the int occurred.

Indeed you should avoid that but i think i will add something to at least avoid the dead lock

Stef wrote:Indeed you should avoid that but i think i will add something to at least avoid the dead lock

Check the current int level in sr and exit immediately instead of waiting.

Chilly Willy wrote:

Stef wrote:Indeed you should avoid that but i think i will add something to at least avoid the dead lock

Check the current int level in sr and exit immediately instead of waiting.

I was thinking about a "in_vintcallback" flag, the SR test is a good idea too but not 100% reliable as now user can set it manually (for instance if you want to do direct VDP command from main loop, you want to avoid V Interrupt callback which generally modify vdp state).

Stef wrote:

Chilly Willy wrote:

Stef wrote:Indeed you should avoid that but i think i will add something to at least avoid the dead lock

Check the current int level in sr and exit immediately instead of waiting.

I was thinking about a "in_vintcallback" flag, the SR test is a good idea too but not 100% reliable as now user can set it manually (for instance if you want to do direct VDP command from main loop, you want to avoid V Interrupt callback which generally modify vdp state).

Okay, how about this -

waitTick:
if (intlevel > 3) wait using VDP status in busy loop
else wait using vints

waitMs:
wait using CPU busy loop (use table lookup for loop count for small ms, use calculation for count for large ms)