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

Announce (tech) demos or games releases

Moderator: Mask of Destiny

mix256
Very interested
Posts: 189
Joined: Thu Jan 25, 2018 2:08 pm
Location: Sweden
Contact:

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

Post by mix256 » Fri May 25, 2018 5:43 am

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. :lol:
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
Very interested
Posts: 3131
Joined: Thu Nov 30, 2006 9:46 pm
Location: France - Sevres
Contact:

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

Post by Stef » Fri May 25, 2018 8:28 am

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
Very interested
Posts: 189
Joined: Thu Jan 25, 2018 2:08 pm
Location: Sweden
Contact:

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

Post by mix256 » Fri May 25, 2018 9:24 am

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
Very interested
Posts: 189
Joined: Thu Jan 25, 2018 2:08 pm
Location: Sweden
Contact:

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

Post by mix256 » Fri May 25, 2018 10:25 am

Haha, look at this:

Image

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
Very interested
Posts: 939
Joined: Thu Apr 10, 2008 3:03 pm
Contact:

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

Post by Sik » Fri May 25, 2018 9:54 pm

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).
Sik is pronounced as "seek", not as "sick".

Miquel
Very interested
Posts: 514
Joined: Sat Jul 30, 2016 12:33 am

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

Post by Miquel » Fri May 25, 2018 11:01 pm

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.
HELP. Spanish TVs are brain washing people to be hostile to me.

mix256
Very interested
Posts: 189
Joined: Thu Jan 25, 2018 2:08 pm
Location: Sweden
Contact:

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

Post by mix256 » Sat May 26, 2018 11:39 am

Sik wrote:
Fri May 25, 2018 9:54 pm
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.
Miquel wrote:
Fri May 25, 2018 11:01 pm
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()... :D
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
Very interested
Posts: 939
Joined: Thu Apr 10, 2008 3:03 pm
Contact:

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

Post by Sik » Sat May 26, 2018 7:07 pm

mix256 wrote:
Sat May 26, 2018 11:39 am
Sik wrote:
Fri May 25, 2018 9:54 pm
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).
Sik is pronounced as "seek", not as "sick".

mix256
Very interested
Posts: 189
Joined: Thu Jan 25, 2018 2:08 pm
Location: Sweden
Contact:

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

Post by mix256 » Sun May 27, 2018 1:09 pm

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
Very interested
Posts: 2984
Joined: Fri Aug 17, 2007 9:33 pm

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

Post by Chilly Willy » Sun May 27, 2018 1:30 pm

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

mix256
Very interested
Posts: 189
Joined: Thu Jan 25, 2018 2:08 pm
Location: Sweden
Contact:

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

Post by mix256 » Sun May 27, 2018 3:36 pm

Chilly Willy wrote:
Sun May 27, 2018 1:30 pm
Pledged. I hope it meets (or exceeds) the goal... I love what I see so far. :D
Super thanks Chilly! I'll try to make the game exceed expectations as well. :D

mix256
Very interested
Posts: 189
Joined: Thu Jan 25, 2018 2:08 pm
Location: Sweden
Contact:

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

Post by mix256 » Wed Jun 13, 2018 6:27 am

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

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? :roll:

Image

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
Very interested
Posts: 3131
Joined: Thu Nov 30, 2006 9:46 pm
Location: France - Sevres
Contact:

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

Post by Stef » Wed Jun 13, 2018 8:39 am

Nice to have some news =)
mix256 wrote:
Wed Jun 13, 2018 6:27 am
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
Very interested
Posts: 189
Joined: Thu Jan 25, 2018 2:08 pm
Location: Sweden
Contact:

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

Post by mix256 » Wed Jun 13, 2018 8:53 am

Stef wrote:
Wed Jun 13, 2018 8:39 am
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
Very interested
Posts: 3131
Joined: Thu Nov 30, 2006 9:46 pm
Location: France - Sevres
Contact:

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

Post by Stef » Thu Jun 14, 2018 10:37 am

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 :)

Post Reply