Progress Thread - Wolfling
Moderator: Moderators
Re: Progress Thread - Wolfling Zero
The PAL NES CPU has 6% fewer cycles per scanline, but there are 50 more lines between NMI and start of next frame. So if you detect PAL NES, run more things before the sprite 0 wait.
Dendy also has 50 more lines, but they're all placed before NMI, and its CPU speed is the same (relative to the PPU) as NTSC. So you can use the same operation ordering as NTSC.
Dendy also has 50 more lines, but they're all placed before NMI, and its CPU speed is the same (relative to the PPU) as NTSC. So you can use the same operation ordering as NTSC.
Re: Progress Thread - Wolfling Zero
PAL has indeed more cycles per frame than NTSC, but a lot of that time is in vblank. If you're waiting for a sprite 0 hit after finishing your PPU updates, you're basically throwing all that time away, and what's left is less than what's in the NTSC visible picture:
NTSC: (240 * 341) / 3 = 27280 cycles
PAL: (240 * 341) / 3.2 = 25575 cycles
PAL only wins if you take the whole frame, including vblank, into account:
NTSC: (262 * 341) / 3 = 29780.666
PAL: (312 * 341) / 3.2 = 33247.5
NTSC: (240 * 341) / 3 = 27280 cycles
PAL: (240 * 341) / 3.2 = 25575 cycles
PAL only wins if you take the whole frame, including vblank, into account:
NTSC: (262 * 341) / 3 = 29780.666
PAL: (312 * 341) / 3.2 = 33247.5
Re: Progress Thread - Wolfling Zero
D'oh!tepples wrote:So if you detect PAL NES, run more things before the sprite 0 wait.
Re: Progress Thread - Wolfling Zero
Maybe it's obvious, but I'd like to share: When short of frame time, I usually measure (visually, via toggling the grayscale bit) individual, short tasks, and make a list of them and the max amount of scanlines they take, so I can move some of them before the sprite 0 hit wait. That will earn you some precious time after it, and you will be throwing away less cycles just waiting. If your hud is, for example, 32 scanlines tall, I'm sure you can stuff some minor tasks right after VBLANK and before the sprite 0 hit wait.
There are some other things you can do to save time. For example, when checking bullets vs enemies collisions, I tend to run the checks in the enemies processing loop, right after I move them, 'cause I tend to cut short the checks - there are more bullets than enemies, and if a collision is registered, you can cut the loop short by discarding every other possible bullet<->enemy collision after you register one for the current enemy. The total amount of checks seems to be shorter this way (looping all the bullets for every enemy) than the way around (looping all the enemies for every bullet). Or maybe I'm talking nonsense. Also, check first for the condition which is more prone to fail, so you can discard subsequent checks: the screen is wider than taller, so checking for X first is a better idea than checking for Y first. There are more chances that the X check fails so you can move to the next entity.
PS - I'm sure there's a better way to measure the amount of scanlines individual tasks take, but I'm still learning
There are some other things you can do to save time. For example, when checking bullets vs enemies collisions, I tend to run the checks in the enemies processing loop, right after I move them, 'cause I tend to cut short the checks - there are more bullets than enemies, and if a collision is registered, you can cut the loop short by discarding every other possible bullet<->enemy collision after you register one for the current enemy. The total amount of checks seems to be shorter this way (looping all the bullets for every enemy) than the way around (looping all the enemies for every bullet). Or maybe I'm talking nonsense. Also, check first for the condition which is more prone to fail, so you can discard subsequent checks: the screen is wider than taller, so checking for X first is a better idea than checking for Y first. There are more chances that the X check fails so you can move to the next entity.
PS - I'm sure there's a better way to measure the amount of scanlines individual tasks take, but I'm still learning
Re: Progress Thread - Wolfling Zero
Update: 4 weeks to go...
The characters... Hunter, tooth and firewolf are not implemented, yet. Uh oh, it's about time!
@na_th_an: Toggling the grayscale bits is my favourite way of visualizing the required CPU time, too. Unfortunately, my code is not modular enough to be moved to the NMI, without a lot of adjustments and there's not enough time left. But after some optimizations, it should be fast enough now. Even for PAL.
Another thing... the guidelines say: "UNROM (2): $FFD0-$FFF9 must be unused."
How do I setup this in the ca65 nes.cfg? Is it ok to define a special section and to fill it with $00?
The characters... Hunter, tooth and firewolf are not implemented, yet. Uh oh, it's about time!
@na_th_an: Toggling the grayscale bits is my favourite way of visualizing the required CPU time, too. Unfortunately, my code is not modular enough to be moved to the NMI, without a lot of adjustments and there's not enough time left. But after some optimizations, it should be fast enough now. Even for PAL.
Another thing... the guidelines say: "UNROM (2): $FFD0-$FFF9 must be unused."
How do I setup this in the ca65 nes.cfg? Is it ok to define a special section and to fill it with $00?
Re: Progress Thread - Wolfling Zero
I just put my DMC sample in the last part of the ROM before the vectors, and made sure it wasn't too long to spill into this area.How do I setup this in the ca65 nes.cfg? Is it ok to define a special section and to fill it with $00?
so, yes, special segment.
nesdoug.com -- blog/tutorial on programming for the NES
Re: Progress Thread - Wolfling Zero
update: 3 weeks left... (uh oh)
Ingame music and a lot of background graphics are still missing, but we have a miniboss...
Ingame music and a lot of background graphics are still missing, but we have a miniboss...
Re: Progress Thread - Wolfling Zero
Is that a web browser mascot I see?
Re: Progress Thread - Wolfling Zero
The smoothness of animation and movements is impressive O_o
- FrankenGraphics
- Formerly WheelInventor
- Posts: 2064
- Joined: Thu Apr 14, 2016 2:55 am
- Location: Gothenburg, Sweden
- Contact:
Re: Progress Thread - Wolfling Zero
Yeah, even with wireframe background, it's a looker!
Re: Progress Thread - Wolfling Zero
update: 2 weeks left
We have more background tiles now. And they're even better than the previous ones. YEAH!
But can we finish the map in time? (drumroll)
@tepples: almost... but then it was called fireWOLF.
We have more background tiles now. And they're even better than the previous ones. YEAH!
But can we finish the map in time? (drumroll)
@tepples: almost... but then it was called fireWOLF.
Re: Progress Thread - Wolfling Zero
update: 1 week left
The new graphics from Zolionline are halfway included, but I have found a lot of additional bugs...
Nevertheless, the game should be finished in the next few days. But only one level.
That's a pity, because there's easily enough ROM space left for two additional levels.
The new graphics from Zolionline are halfway included, but I have found a lot of additional bugs...
Nevertheless, the game should be finished in the next few days. But only one level.
That's a pity, because there's easily enough ROM space left for two additional levels.
- FrankenGraphics
- Formerly WheelInventor
- Posts: 2064
- Joined: Thu Apr 14, 2016 2:55 am
- Location: Gothenburg, Sweden
- Contact:
Re: Progress Thread - Wolfling Zero
At least you have the time between judgement- and cart inclusion if you want to push it further up the hill
Looking forward to see how it plays!
Looking forward to see how it plays!
Re: Progress Thread - Wolfling Zero
That's the good thing. Once the compo is finished, you still have time to add whatever you want so the game in the cart is the best possible rendition.
Re: Progress Thread - Wolfling Zero
Personally, I consider that cheating if it goes beyond game-breaking bug fixes.