Fire Lancer - Hot-Blooded Wonder Shooting - DEMO: DEC.25
Re: Fire Lancer (WIP)
Great music, great look. Looking like a mighty fine game.
-
MintyTheCat
- Posts: 2025
- Joined: Sat Jun 19, 2010 3:46 am
- Location: Germany, Berlin
Re: Fire Lancer (WIP)
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.
More Bromances = safer people
Re: Fire Lancer (WIP)
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.
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.
@trap0xf | daifukkat.su/blog | scores | FIRE LANCER
<S.Yagawa> I like the challenge of "doing the impossible" with older hardware, and pushing it as far as it can go.
<S.Yagawa> I like the challenge of "doing the impossible" with older hardware, and pushing it as far as it can go.
-
MintyTheCat
- Posts: 2025
- Joined: Sat Jun 19, 2010 3:46 am
- Location: Germany, Berlin
Re: Fire Lancer (WIP)
I just read that the WS has "up to 28 sprites per line" https://en.wikipedia.org/wiki/WonderSwa ... ificationstrap15 wrote:I'm well over the hardware sprite limit at times, I multiplex up to 256+56+1+8 sprites with flickering.
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
So do you dedicate some slots for the weapons, ship, HUD that sort of thing and they are never multiplexed as above?trap15 wrote: 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.
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.
More Bromances = safer people
Re: Fire Lancer (WIP)
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.
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.
No, those are just highest priority sprites, so they'll always be on top even through the multiplex scheme.MintyTheCat wrote:So do you dedicate some slots for the weapons, ship, HUD that sort of thing and they are never multiplexed as above?
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.MintyTheCat wrote:Yes, it looks like the WS has 256Mbit = 8MB system RAM and 512KB VRAM - not bad.
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.MintyTheCat wrote: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?
@trap0xf | daifukkat.su/blog | scores | FIRE LANCER
<S.Yagawa> I like the challenge of "doing the impossible" with older hardware, and pushing it as far as it can go.
<S.Yagawa> I like the challenge of "doing the impossible" with older hardware, and pushing it as far as it can go.
Re: Fire Lancer (WIP)
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.
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.
****** My Project: OP90 ******* My Portfolio ******
-
MintyTheCat
- Posts: 2025
- Joined: Sat Jun 19, 2010 3:46 am
- Location: Germany, Berlin
Re: Fire Lancer (WIP)
That is a good idea as many of us never used the machine and would not say "hang on..".trap15 wrote: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.
I see. Yes, it reminds me of the Megadrive's VDP that effects a priority based on the order.trap15 wrote: 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.
Yes, I use the same system myself so the last is always the player's ship and its bullets and little-buddies/helperstrap15 wrote:No, those are just highest priority sprites, so they'll always be on top even through the multiplex scheme.MintyTheCat wrote:So do you dedicate some slots for the weapons, ship, HUD that sort of thing and they are never multiplexed as above?
http://www.nintendolife.com/news/2014/0 ... wonderswantrap15 wrote: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.MintyTheCat wrote:Yes, it looks like the WS has 256Mbit = 8MB system RAM and 512KB VRAM - not bad.
"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.
I get you - a set of tasks each with a TCB (task control block).trap15 wrote: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.MintyTheCat wrote: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?
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
More Bromances = safer people
Re: Fire Lancer (WIP)
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.
@trap0xf | daifukkat.su/blog | scores | FIRE LANCER
<S.Yagawa> I like the challenge of "doing the impossible" with older hardware, and pushing it as far as it can go.
<S.Yagawa> I like the challenge of "doing the impossible" with older hardware, and pushing it as far as it can go.
Re: Fire Lancer (WIP)
https://vine.co/v/evtHebjPPxm Now running on hardware :3
@trap0xf | daifukkat.su/blog | scores | FIRE LANCER
<S.Yagawa> I like the challenge of "doing the impossible" with older hardware, and pushing it as far as it can go.
<S.Yagawa> I like the challenge of "doing the impossible" with older hardware, and pushing it as far as it can go.
Re: Fire Lancer (WIP)
Sweet. Is it comfortable to play TATE games on it?
| My games - http://www.emphatic.se | (Click) I have YEN stickers for sale
RegalSin wrote:Street Fighters. We need to aviod them when we activate time accellerator.
Re: Fire Lancer (WIP)
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.
@trap0xf | daifukkat.su/blog | scores | FIRE LANCER
<S.Yagawa> I like the challenge of "doing the impossible" with older hardware, and pushing it as far as it can go.
<S.Yagawa> I like the challenge of "doing the impossible" with older hardware, and pushing it as far as it can go.
-
MintyTheCat
- Posts: 2025
- Joined: Sat Jun 19, 2010 3:46 am
- Location: Germany, Berlin
Re: Fire Lancer (WIP)
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.trap15 wrote: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.
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?
More Bromances = safer people
Re: Fire Lancer (WIP)
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.
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.
@trap0xf | daifukkat.su/blog | scores | FIRE LANCER
<S.Yagawa> I like the challenge of "doing the impossible" with older hardware, and pushing it as far as it can go.
<S.Yagawa> I like the challenge of "doing the impossible" with older hardware, and pushing it as far as it can go.
-
MintyTheCat
- Posts: 2025
- Joined: Sat Jun 19, 2010 3:46 am
- Location: Germany, Berlin
Re: Fire Lancer (WIP)
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.trap15 wrote: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 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
More Bromances = safer people
Re: Fire Lancer (WIP)
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.trap15 wrote: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.
anyway, def looking forward to trying this game
Re: Fire Lancer (WIP)
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.
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.
@trap0xf | daifukkat.su/blog | scores | FIRE LANCER
<S.Yagawa> I like the challenge of "doing the impossible" with older hardware, and pushing it as far as it can go.
<S.Yagawa> I like the challenge of "doing the impossible" with older hardware, and pushing it as far as it can go.
Re: Fire Lancer (WIP)
@trap0xf | daifukkat.su/blog | scores | FIRE LANCER
<S.Yagawa> I like the challenge of "doing the impossible" with older hardware, and pushing it as far as it can go.
<S.Yagawa> I like the challenge of "doing the impossible" with older hardware, and pushing it as far as it can go.
Re: Fire Lancer (WIP)
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
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
Re: Fire Lancer (WIP)
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).
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).
@trap0xf | daifukkat.su/blog | scores | FIRE LANCER
<S.Yagawa> I like the challenge of "doing the impossible" with older hardware, and pushing it as far as it can go.
<S.Yagawa> I like the challenge of "doing the impossible" with older hardware, and pushing it as far as it can go.
Re: Fire Lancer (WIP)
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/
http://firelancer.ws/story/
@trap0xf | daifukkat.su/blog | scores | FIRE LANCER
<S.Yagawa> I like the challenge of "doing the impossible" with older hardware, and pushing it as far as it can go.
<S.Yagawa> I like the challenge of "doing the impossible" with older hardware, and pushing it as far as it can go.
-
Squire Grooktook
- Posts: 5969
- Joined: Sat Jan 12, 2013 2:39 am
Re: Fire Lancer (WIP)
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)
(I would leave it that way if not intentional, it's cool)
Aeon Zenith - My STG.RegalSin wrote:Japan an almost perfect society always threatened by outsiders....................
Instead I am stuck in the America's where women rule with an iron crotch, and a man could get arrested for sitting behind a computer too long.
Re: Fire Lancer (WIP)
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
@trap0xf | daifukkat.su/blog | scores | FIRE LANCER
<S.Yagawa> I like the challenge of "doing the impossible" with older hardware, and pushing it as far as it can go.
<S.Yagawa> I like the challenge of "doing the impossible" with older hardware, and pushing it as far as it can go.
-
tiaoferreira
- Posts: 252
- Joined: Fri Aug 21, 2009 9:29 pm
- Contact:
Re: Fire Lancer (WIP)
Marvelous concepts!
-
CStarFlare
- Posts: 3002
- Joined: Tue Feb 19, 2008 4:41 am
Re: Fire Lancer (WIP)
How're things coming along? I was so excited when you said mighty close.
Re: Fire Lancer (WIP)
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.
@trap0xf | daifukkat.su/blog | scores | FIRE LANCER
<S.Yagawa> I like the challenge of "doing the impossible" with older hardware, and pushing it as far as it can go.
<S.Yagawa> I like the challenge of "doing the impossible" with older hardware, and pushing it as far as it can go.
Re: Fire Lancer (WIP)
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.
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.
@trap0xf | daifukkat.su/blog | scores | FIRE LANCER
<S.Yagawa> I like the challenge of "doing the impossible" with older hardware, and pushing it as far as it can go.
<S.Yagawa> I like the challenge of "doing the impossible" with older hardware, and pushing it as far as it can go.
Re: Fire Lancer (WIP)
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.
Re: Fire Lancer (WIP)
Yeah, I just spent some now toning down the shrapnel and reducing their flashing. Might play with different bullet colors in a bit.
@trap0xf | daifukkat.su/blog | scores | FIRE LANCER
<S.Yagawa> I like the challenge of "doing the impossible" with older hardware, and pushing it as far as it can go.
<S.Yagawa> I like the challenge of "doing the impossible" with older hardware, and pushing it as far as it can go.
Re: Fire Lancer (WIP)
Stunning. What does the boss say?
| My games - http://www.emphatic.se | (Click) I have YEN stickers for sale
RegalSin wrote:Street Fighters. We need to aviod them when we activate time accellerator.
Re: Fire Lancer (WIP)
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.
@trap0xf | daifukkat.su/blog | scores | FIRE LANCER
<S.Yagawa> I like the challenge of "doing the impossible" with older hardware, and pushing it as far as it can go.
<S.Yagawa> I like the challenge of "doing the impossible" with older hardware, and pushing it as far as it can go.