Fire Lancer - Hot-Blooded Wonder Shooting - DEMO: DEC.25

[lilmanjs]

Great music, great look. Looking like a mighty fine game.

[MintyTheCat]

Uploaded preview two-oh. https://youtu.be/W2JtsZKchIc

Getting mighty close.

It looks smoother scroll wise to me.

Can I ask: sprite limit wise how close is the game running to reaching its limit?
Also, when a bomb is pressed are you using any object-slots that were occupied previously by enemies or do you have enough at all times for a screen bomb and all the enemies on screen to have their own slot?

Cheers,

Minty.

[trap15]

I'm well over the hardware sprite limit at times, I multiplex up to 256+56+1+8 sprites with flickering.

The bomb doesn't take over anything, it just deals global damage and spawns lots of explosions. I haven't run into a case yet where I've run out of task slots, as I went the safe route and made the array a bit larger than necessary.

[MintyTheCat]

I'm well over the hardware sprite limit at times, I multiplex up to 256+56+1+8 sprites with flickering.

I just read that the WS has "up to 28 sprites per line" https://en.wikipedia.org/wiki/WonderSwa ... ifications
Does this mean that a line is a NxM pixel block or is it a single pixel - I would think it would be a block for a tile.
I am trying to work out how many sprites the WS allows on the screen at any time so that I can work out how far over the limit you are.
So the multiplex is based on priorities of the enemies or do you split the table into a number of parts and update one section at a time, remove the next section for the duration and the next until you loop back to the first section and hence the flicker?

Apologies if these are more technical questions but I am interested and since you are the only chap who is working on a Retro platform here I simpyl have to ask

The bomb doesn't take over anything, it just deals global damage and spawns lots of explosions. I haven't run into a case yet where I've run out of task slots, as I went the safe route and made the array a bit larger than necessary.

So do you dedicate some slots for the weapons, ship, HUD that sort of thing and they are never multiplexed as above?
Yes, it looks like the WS has 256Mbit = 8MB system RAM and 512KB VRAM - not bad.
How much memory does the event-table for your enemies occupy?
Also, have you compressed any of the event-table entry data or it is raw and expanded?

Cheers,

Minty.

[trap15]

That article is amazingly wrong, holy shit. I should go in and fix it probably. It's 32 sprites per line, 128 total, 8x8. I obviously use them in bunches to make larger sprites.

It's a traditional line-buffer VDP design, so it only renders a line at a time, so it just drops any sprites beyond 32 each line. My multiplexing scheme handles this as well, but it's nothing unique. It's the same technique used on NES a lot to get around that platform's stingy 8 sprite limit. Essentially every even frame I go from the front of the list forward (which keeps everything in proper priority), and every odd frame I go from the end of each priority's list backwards. This way, two overlapping sprites in the same priority will flicker, and when you lose sprites from going over the total count or the line count, it's not going to go away forever.

So do you dedicate some slots for the weapons, ship, HUD that sort of thing and they are never multiplexed as above?

No, those are just highest priority sprites, so they'll always be on top even through the multiplex scheme.

Yes, it looks like the WS has 256Mbit = 8MB system RAM and 512KB VRAM - not bad.

I have no idea where you got those numbers, as they're faker than George Washington's teeth. WSC has 64KB internal RAM, which is shared for the sprite table, tiles, tilemaps, palettes, and sound wavetable. I opted to not use the IRAM for general RAM, and am instead using 64KB of on-cart SRAM instead, just using the IRAM for system memory.

How much memory does the event-table for your enemies occupy?
Also, have you compressed any of the event-table entry data or it is raw and expanded?

Not sure what you mean, that's not how my engine works. It's just got an abstract concept of a "task" (up to 96) with a callback that runs every frame and associated work data (up to 124 bytes). In total the task array is 12KB.

[Wyeth]

Loving the style super low-fi for the win!

The music is great and the SFX seem fitting. I quite like the "moving back to change modes" thing. I mean I guess thats not revolutionary but it just really like it, cuts down on additional buttons.

It's always hard to judge how it would really feel without having a demo or something playable in ones hand, it does look like it would feel really good though.

Looking forward to the release.

[MintyTheCat]

That article is amazingly wrong, holy shit. I should go in and fix it probably. It's 32 sprites per line, 128 total, 8x8. I obviously use them in bunches to make larger sprites.

That is a good idea as many of us never used the machine and would not say "hang on..".

It's a traditional line-buffer VDP design, so it only renders a line at a time, so it just drops any sprites beyond 32 each line. My multiplexing scheme handles this as well, but it's nothing unique. It's the same technique used on NES a lot to get around that platform's stingy 8 sprite limit. Essentially every even frame I go from the front of the list forward (which keeps everything in proper priority), and every odd frame I go from the end of each priority's list backwards. This way, two overlapping sprites in the same priority will flicker, and when you lose sprites from going over the total count or the line count, it's not going to go away forever.

I see. Yes, it reminds me of the Megadrive's VDP that effects a priority based on the order.

So do you dedicate some slots for the weapons, ship, HUD that sort of thing and they are never multiplexed as above?

No, those are just highest priority sprites, so they'll always be on top even through the multiplex scheme.

Yes, I use the same system myself so the last is always the player's ship and its bullets and little-buddies/helpers

Yes, it looks like the WS has 256Mbit = 8MB system RAM and 512KB VRAM - not bad.

I have no idea where you got those numbers, as they're faker than George Washington's teeth. WSC has 64KB internal RAM, which is shared for the sprite table, tiles, tilemaps, palettes, and sound wavetable. I opted to not use the IRAM for general RAM, and am instead using 64KB of on-cart SRAM instead, just using the IRAM for system memory.

http://www.nintendolife.com/news/2014/0 ... wonderswan
"and system RAM was increased to 256 Mbit" - Some porkies..

Ok, it is the same as the MD with 64KB of RAM but shared with the Z80 and 68K - I call it Work-RAM.
Yes, it makes sense to use the ROM as you get more of it and as many things are 'scripted' for a Shmup it does not need to be modified so it is wasteful to make it taking up your WRAM - makes sense.

How much memory does the event-table for your enemies occupy?
Also, have you compressed any of the event-table entry data or it is raw and expanded?

Not sure what you mean, that's not how my engine works. It's just got an abstract concept of a "task" (up to 96) with a callback that runs every frame and associated work data (up to 124 bytes). In total the task array is 12KB.

I get you - a set of tasks each with a TCB (task control block).
So you callback is your tasks that acts as a scheduler or task-selector and swaps in and out your tasks, their context (regs and such). This reminds me of some of the small RTOS I have used.

I have something similar in that each Object-ID is mapped to its own handler Routine - not really this idea of having a Task as such it is more that the Super-Loop works out what needs to be executed.
However, my Shmup Engine is in its early stages so may change a lot

Cheers for the explanations, Trap and yes, it would be good if the Wikipedia page matched reality

[trap15]

Nah, it's not a real scheduler. More like a list of callbacks and associated data. I just iterate through the array every frame and run each thing. Very simple, low overhead, very flexible.

[trap15]

https://vine.co/v/evtHebjPPxm Now running on hardware :3

[emphatic]

Sweet. Is it comfortable to play TATE games on it?

[trap15]

It's pretty comfortable. Only gripe is the pads being segmented (understandable, as they're more general purpose inputs than pads) combined with how raised out from the body they are, makes it a bit tough to roll your thumb across. But it's not that big of a problem, it's quite usable.

[MintyTheCat]

Nah, it's not a real scheduler. More like a list of callbacks and associated data. I just iterate through the array every frame and run each thing. Very simple, low overhead, very flexible.

I agree. I find that most of the time a Scheduler has to be able to handle the general case but handling a Shmup's resources is a very particular case.

Profiling wise: how much of the machine's processing power do you have left over at any time? Also, can you gauge the amount easily?

[trap15]

CPU time is much lower on hardware compared to emulator for some reason. On emulator I start breaking the 13.25ms threshold with about 6 to 8 enemies on screen and player firing. On hardware, that is lowered to 3 enemies and player firing. I'm going to continue to work on optimization until the performance is closer to what the emulator is at.

I came up with a good way to do cycle-accurate profiling the other day (latest blog post covers it), but I haven't integrated it into Fire Lancer yet. I suppose I probably should.

[MintyTheCat]

I came up with a good way to do cycle-accurate profiling the other day (latest blog post covers it), but I haven't integrated it into Fire Lancer yet. I suppose I probably should.

I read your blog entry: now that's a handy piece of info there It reminds me of having capture-compare on a timer tied to an interrupt.

I shall have a look at your test-harness too some time this week.

Nice work there and a useful method that you have worked out

[e_tank]

On emulator I start breaking the 13.25ms threshold with about 6 to 8 enemies on screen and player firing. On hardware, that is lowered to 3 enemies and player firing. I'm going to continue to work on optimization until the performance is closer to what the emulator is at.

are you using a broad phase to cull unnecessary player_bullet vs enemy tests? not sure but from the gameplay video it looks like the player ship can put a lot of player_bullets on screen at once, implementing something like a simple uniform grid based broad phase should net you a decent speedup with minimal effort in your collision testing code.

anyway, def looking forward to trying this game

[trap15]

I've never quite understood how such a thing can improve performance unless sorting is cheaper than collision testing, which isn't true here. Maybe I'm just not thinking of the right sorting algorithms, but my thought is I'll either blow my memory budget (new optimization has cut down the RAM I have a lot) or take much longer than just doing the collision checks.

Speaking of new optimization, I found out that the on-cart SRAM is only an 8-bit data bus, so using it instead of IRAM has 2x latency on word access. I did a bunch of gymnastics and now I use IRAM for my BSS section (most of my RAM usage), which has given me a pretty nice boost on hardware and lets me use DMA a lot more which gives big gains on both HW and emu.

[trap15]

Just set up a website. Intending to put more content on it soon maybe.

http://firelancer.ws/

[e_tank]

a uniform grid doesn't require sorting objects, you're probably thinking of sweep and prune (aka sort and sweep), which is another commonly used broad phase method that works via maintaining sorted list(s) of objects between frames (tho s&p typically isn't a good fit for stg's, where you may have a large number of objects but only certain groups of these actually collide with each other). on the other hand a uniform grid is exactly what it sounds like, you overlay a uniform grid over the screen and place objects into the cell(s) they overlap. so instead of having a time complexity of m * n (tests), where m = player_bullets and n = enemies, with a uniform grid you can get something like m (inserts) + kn (tests) time complexity where on avg k is some small number. obviously there's some overhead involved, a combination of time and memory that will typically be inversely proportional based on the implementation (how you represent the grid/cells internally, how the cells are spaced out, do you restrict objects to a single cell, etc), but for your use case it prob wouldn't require that much of either.

regarding your first concern, memory usage, while i can't say for sure i don't see it requiring more than an additional .5kb total (that assumes use of a dense array of object pointers to represent the grid, it can be modified to require (a lot) less with varying affect on time complexity)

regarding your second concern, that a brute force solution being faster anyway, that's plausible. there exists a tipping point based on the number of objects that must be tested against each other + the cost of your narrow phase pairwise collision tests where it becomes more efficient than not to have a broad phase. where your game currently lies on that scale i couldn't say (w/o knowing the inner workings of your game). but if i had to guess i think it would be at least slightly faster with one, but it prob would require some specific optimizations that place restrictions on enemy and player_bullet size to make it worthwhile (ex: with an appropriate cell size and using an r-type like approach where you treat your player_bullets as points while expanding the aabb/circle of your enemy to compensate, each enemy would only need to check at most 4 cells for player_bullets in the grid).

anyway all this is prob moot at this point, as im sure moving all your variables to ram that's not gimped in bandwidth nets you a much bigger speed boost than what having a broad phase would get you, unless you intend to really ramp up the number of player_bullets and enemies on screen.

quick question on the wswan for you though, and if you don't know off the top of your head don't bother looking it up as i'm just asking out of curiosity, but does the wswan allow you to change sprite data during hblank? the gba let you do this, and i know of at least one game that used it to extend the normal amount of max sprites allowed on screen at once. kind of a cool feature if you ask me

[trap15]

Interesting info on the uniform grid, I'll look into it more. The RAM speedup and a recent refactor of enemy handling has made the performance quite nice, but I'm still not always hitting 100% so anything is handy.

I "can" change sprites even during active display, but sprites are DMAd at the end of each frame so I can't change the displayed sprites. Using the DMA behavior I actually am double buffering my sprites (RAM address for sprite table can be moved, so I barf out the sprite data then flip the buffer address) so that I don't end up with glitching sprites during slowdown. Sprite glitching would happen otherwise as I'm not waiting on a vblank rising edge for my frame limiting, which allows me to get "smooth" slowdown that isn't in FPS/X steps (very critical for a game like this, imo).

[trap15]

Put up a story and some other stuff on the website. Kind of unsure how much I want to show in the GAME SYSTEM page, don't want to reveal everything

http://firelancer.ws/story/

[Squire Grooktook]

I like how the story doesn't specify which side you're on.

(I would leave it that way if not intentional, it's cool)

[trap15]

I felt it was implied enough that it wasn't necessary to specify. The enemy sprite design also should make it more obvious. But yeah, I see no reason to elaborate any further. Letting the mind wander and come up with stuff on its own is better than intricate detail

[tiaoferreira]

Marvelous concepts!

[CStarFlare]

Uploaded preview two-oh. https://youtu.be/W2JtsZKchIc

Getting mighty close.

How're things coming along? I was so excited when you said mighty close.

[trap15]

Decently well, lots of optimization and things, work on stage layouts, things of that nature. Doing a location test at Touhoucon this weekend for some feedback. Still need a non-placeholder BG; biggest show-stoppers still are boss design, BG, and music.

[trap15]

New preview video finally: https://youtu.be/YjTpAOlzHHY

Within 10 minutes of posting, like 4 people were like "holy shit I can't even see anything" so maybe I'll have to make the shrapnel stuff less visible or the bullets even more visible. I dunno. I think it's fine, but... I also think it's easy which it's apparently not. So, I'll have to look into it.

[Shepardus]

I'm having trouble distinguishing bullets from shrapnel because they're so similar in color - they're both a combination of red and yellow. Maybe you should play around with changing the colors of one of them.

[trap15]

Yeah, I just spent some now toning down the shrapnel and reducing their flashing. Might play with different bullet colors in a bit.

[emphatic]

Stunning. What does the boss say?

[trap15]

It's the "MAKE MY DAY" voice clip from FixEight. Purely temporary, but hilarious. It was the testing sample I used when I was getting HyperVoice hooked up.