No. I had to go into the settings and change the volume. It was at 0 by default. Also the game were zoomed in and I couldn't see all the UI. So I had to use borderless window to play. Also, I'm on MacOS, which is non-typical I would assume so that could be a reason why it was like that.
You have been working alot with your scanline sprite render. I'm curious how many sprites you can realistically push in a single hblank. Is there a big difference the sprites are copied from IWRAM vs EWRAM for example?
What are your experiences? What's the limit from your testing (I assume you have fine-tuned this limit to push the graphics of your newest racing sim).
Also, do you always push the same amount of scanlines each hblank or do you use interrupts to fine-tune the amount depending on the geometry on screen?
Not Abandoned :) But progress is slow atm. I've recently moved into a house so normal life has taken some time from the project. I also write my own GBA hardware abstraction library in rust, so currently there is still a lot of effort going into that as well.
Really cool graphics! Don't think I've seen something like this on the gba. Gameplay is somewhat repetitive but the different enemies makes it up. A map would be helpful. It's very easy to get lost. Especially if you rotate the map alot!
Managed to finish the boss. I think I was over-leveled after getting lost somewhat. Each hit made 9 damage and he went down in a few seconds.
This game felt really polished! Good job :D Camera movement was really nice. Rotating the world looks super good!
The only negative aspect I can think of is that once you learn how to play (e.g try to progress until you are stuck, then rotate the world until you see a reachable platform), the level design felt somewhat repetitive. But that could easily be solved with puzzles, additional game mechanics and backtracking.
Overall, a great entry!
Do you plan to make a full game out of it or do you consider it finished?
Thanks for the feedback! I'm actually cheating a bit with the friction calculations to make it run faster. But it's so fast so I will probably come back and make it more accurate in the future. I plan to use the physics in some core gameplay items that will enable some cool interactions!
For context: I tried to "innovate" somewhat, by incorporate a button schema which would enable a-lot of actions. In retrospect, I agree that it's confusing and overly complicated.
I have some new ideas on aiming that will be more simple and more conventional:
I plan to skip the current L behavior (aim in moving direction) aiming for a typical lock-on when pressing L. Locking on "nothing" just "locks-in" the current direction the character is facing, and the dpad will let you move freely while the aim is locked in that direction.
If you use a ranged item (equipped to A or B) while locked-on, you can move freely while aiming.
If you want to aim freely, you will have to use an equipped ranged item first, while not pressing L (no locked-on target).
If you press lock-on while the cursor hovers on a target, you will move to state 1.1. and lock-on that target, and the dpad lets you move freely.
If you press lock-on while no target is hovered, you will go to state 1 where the aim locks in the direction of the cursor you had while free-aiming, and the dpad will control the character.
R still performs a roll.
Will probably have to iterate further but i think this is an improvement on your feedback.
Also, more animations will come! I have not yet settled on the character sprite so for now, I have paused working on animations until I have actual gameplay.
