Tänzer, a "ninja" game (Dev Diary thread)

[mix256]

Just had a go in Fusion with NTSC region. It slows down quite a bit more, and some of the animations just look ridiculous.
I guess most releases today are multi-region ones, but I don't think I'll be able to pull that off easily, will need to have different enemy placements and animation timings as well as the number of frames in certain animations. It would be much easier to handle all of this when generating the resources so I think I'm going to have to do separate releases. Which is, in itself, quite cool.

Also, I'm going in Kickstarter thoughts. Especially now when I need to get a JAP and a US NTSC machine to test with as well.
It would be my first, though, so I wouldn't know how to do a proper one.

I can't really release a demo until I sort all of this out, and I still haven't found the source of the intermittent adress error bug. So...

[Stef]

I really recommend you to develop the NTSC version first as this is the version almost people will use, also going from NTSC to PAL is almost never a problem (it just makes the game feel slower) while the opposite is much more complicated : many bugs and slowdown can happen as bandwidth is much more limited, also gameplay as animation can severely be affected (too fast).

Even if you only have a PAL system to test it, test the gameplay mechanic and generals bugs with emulators first (in NTSC mode so) then test on your PAL system only to get rid of more obscure bugs (as address error).

[mix256]

Yeah, that's why I want two versions.
One that uses the bandwidth to its max and one that uses the speed to its max. Sure, it will take more work but it will be worth it, I think.

[mix256]

Haha, look at this:



See all that white raster time being spent on something? Yeah, it's totally unnecessary as well. It's the time taken to draw the front bkg layer.
Made me a happy puppy to find that bug. \o/

[Sik]

Making a dumbed down NTSC version is pretty much guaranteed to cause outrage. Don't do that.

Also you'll probably find out that the real issue is that the game is likely unoptimized and there's a lot of opportunity to improve how things are done (and enough to make everything fit in NTSC).

[Miquel]

How do you update to vdp memory the new columns on planes A & B?

There are 2 options:
- Buffer it and do that just after vertical exception
- Or doing it during display time when you update your game data

The thing is: it's more than 10 times faster to do it in a vertical blank, I found it the hard way when my game slow down only when scrolling both directions.

Also do it with a dma and autoincrement for max efficiency, it will block the cpu but at least will be really fast.

[mix256]

Making a dumbed down NTSC version is pretty much guaranteed to cause outrage. Don't do that.

Also you'll probably find out that the real issue is that the game is likely unoptimized and there's a lot of opportunity to improve how things are done (and enough to make everything fit in NTSC).

Depends on what you mean by dumb down, I guess.
I would like to have as much blood splats, explosions etc on screen as possible. And since the NTSC raster time is less, it will have less of this than the PAL version. If I optimize it only means I can have more in the PAL version as well, but still the NTSC will have less.

How do you update to vdp memory the new columns on planes A & B?

There are 2 options:
- Buffer it and do that just after vertical exception
- Or doing it during display time when you update your game data

The thing is: it's more than 10 times faster to do it in a vertical blank, I found it the hard way when my game slow down only when scrolling both directions.

Also do it with a dma and autoincrement for max efficiency, it will block the cpu but at least will be really fast.

As it is now, it's totally unoptimized. The function is even called drawTile_Slow()...
I've split the drawing of the tiles over 4 frames, since I know the max movement speed. That's the only thing I've done to it. Will look into the VDP_setTileMapDataRect() function next which seems to be using autoinc.
Thanks!

[Sik]

Making a dumbed down NTSC version is pretty much guaranteed to cause outrage. Don't do that.

Also you'll probably find out that the real issue is that the game is likely unoptimized and there's a lot of opportunity to improve how things are done (and enough to make everything fit in NTSC).

Depends on what you mean by dumb down, I guess.
I would like to have as much blood splats, explosions etc on screen as possible. And since the NTSC raster time is less, it will have less of this than the PAL version. If I optimize it only means I can have more in the PAL version as well, but still the NTSC will have less.

The way you worded it implied that you may go as far as removing enemies and such.

Even then, first try to optimize the code, chances are eventually other you'll hit limits before NTSC-specific ones once you do that (e.g. hitting sprite limits or running out of memory).

[mix256]

So, did a kickstarter after all. My first ever.

https://www.kickstarter.com/projects/83 ... lusive-gam

And the game will be a multicart one as well. Just ordered a Genesis.

[Chilly Willy]

Pledged. I hope it meets (or exceeds) the goal... I love what I see so far.

[mix256]

Pledged. I hope it meets (or exceeds) the goal... I love what I see so far.

Super thanks Chilly! I'll try to make the game exceed expectations as well.

[mix256]

Long time no update, again. Got a lot on my plate now and one reason is that the Kickstarter seems to be successful. Yay!

At the moment I'm struggling with a sprite limit thing. It seems that when a SPR_addSprite() returns NULL, there is no way to recover from it.
Will need to investigate that a bit more and try the new SPR_defragVRAM() that Stef implemented.

I'm waiting for my NTSC Genesis to arrive. Hoping to get it this week...but the postal service here nowadays aren't too reliable.
Will be interesting to see how the game runs on it, my computer here can't emulate for shit so I can't use that as a bench mark.

And we have a new enemy in the level, how could I have forgotten about the bisons?



In other news, I'm in discussions regarding having someone else redraw my main character to make it dance a bit more (I've started on this myself several times but the result is not worthy of the game).
Also, cut scenes have been talked about with several people. I will at least have something after having finished the level (a level contains several stages). Something like in 1943, when you see the boss going down in smokes in the background and your plane animates in in-front of it.

Later!

[Stef]

Nice to have some news =)

At the moment I'm struggling with a sprite limit thing. It seems that when a SPR_addSprite() returns NULL, there is no way to recover from it.
Will need to investigate that a bit more and try the new SPR_defragVRAM() that Stef implemented.

Oh really ? you mean that when SPR_addSprite() returns NULL then the sprite engine is broken ? or that you can't simply use SPR_release(..) to make another add ? using VRAM defrag can help in this situation indeed

[mix256]

Oh really ? you mean that when SPR_addSprite() returns NULL then the sprite engine is broken ? or that you can't simply use SPR_release(..) to make another add ? using VRAM defrag can help in this situation indeed

I've got NULL-guards around all of the SPR_x() functions (each are wrapped in new functions), so when the add returns NULL everything will continue as normal. The game actors will exist as if there was sprites attached to it, but the returned sprites from add won't be used.

But it seems that as soon as one of the adds return NULL (I set the border color to yellow just to mark it) the sprite engine behaves really strange. Sprites added afterwards that don't return NULL aren't shown properly (large chunks of tiles missing) and sometimes after a while after this happens, the whole game hangs (which isn't a surprise if the sprites aren't really valid).

Any suggestions welcome.

I did try to do a defrag when this happened as well, but the exact same behavior was seen.

[Stef]

Can you try to use the library in debug mode ? it will thrown message in KMod output window when error occurs, that might be easier to spot the issue