|
ForumsSega Master System / Mark III / Game GearSG-1000 / SC-3000 / SF-7000 / OMV |
Home - Forums - Games - Scans - Maps - Cheats - Credits Music - Videos - Development - Hacks - Translations - Homebrew |
Goto page Previous 1, 2 |
Author | Message |
---|---|
|
Posted: Sun Mar 31, 2024 12:06 am |
Had to take a break from programming today.
Added a guy to the title screen, not sure if I'll do anymore with it yet, I might animate the laser. |
|
|
Posted: Mon Apr 01, 2024 8:03 pm |
Started doing boss stuff.
I had considered vertical scrolling/moving boss but quickly gave up on that idea, plus I think horizontal only is fine for this game. |
|
|
Posted: Tue Apr 02, 2024 7:42 am |
Wow, it looks really great now! | |
|
Posted: Tue Apr 02, 2024 8:23 am |
it's so cool !
Can't wait to see the rest. |
|
|
Posted: Tue Apr 02, 2024 11:04 pm |
Thanks!
Another work in progress boss. |
|
|
Posted: Wed Apr 10, 2024 8:54 pm |
Small bump with the jungle stage preview. This might be the last stage background I show before the game is finished I think.
Lots of enemy sprites and enemy events to do next. |
|
|
Posted: Wed Apr 17, 2024 6:46 pm |
Freed up some tiles on the volcano stage so added some more lava to give it some movement.
Added 3 new enemy sprites today too, a lot left to do... Sound and music is complete and in the game though. |
|
|
Posted: Thu Apr 25, 2024 7:04 pm |
Small bump. Starting to design enemy and stage patterns now.
There seems to be plenty of CPU time left for more bullets but this enemy will probably do something more interesting. |
|
|
Posted: Thu Apr 25, 2024 7:56 pm |
Great job! I follow your progress via X, and your game seems to me to have nothing to envy compared to commercial games for the SMS in the 90s. | |
|
Posted: Thu Apr 25, 2024 10:10 pm |
Looks great. Can't wait to play it.
Please go easy with the color purple. It's a dead give away that the game is not designed by graphic designers. Me personally, I really hate the color purple in video games. But if it's just me then ignore the rant. lol. |
|
|
Posted: Fri Apr 26, 2024 8:03 am |
Thanks Aranya! |
|
|
Posted: Fri Apr 26, 2024 8:56 am |
Thanks! I'm sorry you don't like purple but I probably won't change much, particularly on the backgrounds. It's a good compliment to yellow, which I'm sure you understand if you're a graphic designer. I recently added a darker red to the sprite palette so that will replace purple in a lot of places though. |
|
|
Posted: Fri Apr 26, 2024 9:20 am |
Speaking of graphic designers, I am one and I have no problems whatsoever with the color purple. I think your graphics are excellent and your choice of color in particular is outstanding.
What I’m not too sure about is that the origin of the player's shots is off-center of the player sprite. I understand it from a graphical point of view, but I think it might feel weird and require much getting used to in regards to the gameplay. |
|
|
Posted: Fri Apr 26, 2024 10:59 am |
[quote="Kagesan"]Speaking of graphic designers, I am one and I have no problems whatsoever with the color purple. I think your graphics are excellent and your choice of color in particular is outstanding.[quote]
Thanks!
That's a good point, the player is more visible than the player gun so it makes sense. I'll try it centred for a while and see how it feels. |
|
|
Posted: Fri Apr 26, 2024 1:27 pm |
Hello and first of all congratulations for the development made so far, it looks stellar!
This reminds me of some games which happened to have the shots off-centered: Time Soldiers and Rambo-first-blood-part-2 (although technically they might not qualify as "fixed screen shoot-em-up" though). Just wanted to throw in this :) |
|
|
Posted: Fri Apr 26, 2024 7:57 pm |
Thanks!
I like Time Soldiers but wasn't a big fan of the guns to the side, it seems to work less well with 8 directions. |
|
|
Posted: Fri Apr 26, 2024 8:02 pm |
Continuing work on this mid boss.
Starting work on enemies with the mid boss turned out to be a good idea, as a mid boss like this has allowd me to work on simple movement and shooting functions and also branching patterns that big bosses have. I have a lot of the underlying code in place for small enemies and bosses now, but building good/fun enemy patterns is gonna take a lot of time... |
|
|
Posted: Sat Apr 27, 2024 8:52 am |
Some WIP screenshots/marketing. These stages will likely be the "back of the box" shots. There are two other stages that won't be revealed until some time after release.
|
|
|
Posted: Sat Apr 27, 2024 10:23 am |
Gorgeous looking game, much like your last game. The palette really pops. Very nice job on all your designs. | |
|
Posted: Sat Apr 27, 2024 11:46 am |
Have been following you on Twitter!!! Awesome game...crossing my fingers for a physical release. Keep up the good work!!! |
|
|
Posted: Sat Apr 27, 2024 1:09 pm |
Thanks guys!
I'm hoping for a physical release too, but just focussing on finishing the game for now. |
|
|
Posted: Sat Apr 27, 2024 7:53 pm |
I believe your game definitely deserves a physical release.
"There are two other stages that won't be revealed until some time after the release." I like this kind of secrets/surprises. |
|
|
Posted: Sun Apr 28, 2024 7:12 pm |
Thanks, yes plenty of surprises still left to show! And the soundtrack by Crisps, which takes about half the ROM! |
|
|
Posted: Fri May 03, 2024 12:28 pm |
I'm currently adding little animations and bits that might drain the CPU. I decided it might be best to add these before building the stage events (enemy spawning), so I know how many enemies and bullets I can get on screen.
Spawning aimed enemy bullets is probably the biggest single-frame CPU hit, even with a lookup table for atan2, so I'm spacing those out appropriately. |
|
|
Posted: Fri May 03, 2024 3:13 pm |
Why do you want to actually calculate the trajectory? For Flight of Pigarus I used four lookup tables with hardcoded x/y speed values for 16 directions. I only had to check the player's position relative to the enemy bullet source to assign the correct values to the bullet entity. The tables didn’t get more granular than 8x8 pixel cells and the accuracy of the aim was still more than sufficient. In your case, things could even be simpler, since your player's y position is fixed. That way you get aimed bullets with a minimum of cpu time wasted. |
|
|
Posted: Fri May 03, 2024 4:39 pm |
Hmm maths is not my strong point (to put it mildly) so I could be over-engineering the problem. I have an atan2 LUT (2d array) 32x24 which holds a value for each 8x8 pixel cell. I calculate the enemy-player offset and round to 8x8 pixel coord, and use those coords to get the atan2 value, and then use that to fetch the velocity from the SIN/COS LUT. This is the function: (create_next_* are globals for the next "creation" event normally set/used elsewhere) bool enemy_bullet_aimed_create(void) { if (num_enemy_shots >= MAX_ENEMY_SHOTS) { return false; } static signed int dx, dy; static unsigned char atan_two; dx = (FIXED_TO_INT(player_x) + 8) - (create_next_at_x + 4); dy = (FIXED_TO_INT(player_y) + 8) - (create_next_at_y + 4); atan_two = atan2_get((dy + 4) >> 3, (dx + 4) >> 3); SMS_mapROMBank(CODE_BANK_1_NUM); // SIN_LUT create_next_vx = SIN_LUT[atan_two + 64] << 2; create_next_vy = SIN_LUT[atan_two] << 2; static EnemyShot *s; s = &enemy_shots[num_enemy_shots++]; enemy_shot_set_new(s); s->update_func = enemy_bullet_update; return true; } One thing is I still need to be able to adjust velocity of aimed bullets based on 3 difficulty levels, but that's not included in the function yet. Open to any suggestions for changes/improvements! |
|
|
Posted: Fri May 03, 2024 5:21 pm |
As an addition to the above, I'm using only 16 directions for enemy movement events to keep it simple to construct paths, but I felt it didn't offer enough accuracy for aimed bullets. Some shot were missing and the player didn't have to move. | |
|
Posted: Sat May 04, 2024 6:16 am |
Your method doesn't seem terribly inefficient, actually. It's quite similar to what I do.
Look at the attached picture. (Ignore the black bars at the top and at the left, I handle those directions elsewhere.) Each of the cell colors represents one of 16 directions an enemy bullet can be shot. The table shown is for the case that the player is below and to the right of the enemy. I've got three similar maps for the other three possibilities. I total, there are 64 directions the enemies can shoot. For determining the direction the enemy has to shoot, I just have to calculate in which cell relative to the enemy the player is. ;=================================================================================
; Set direction for aimed shots ;================================================================================= ; expects enemy xy in de ; destroys a, hl ; returns direction (0-63) in a .section "aiming" free AimAtPlayer: ld a, :AimingTable ; change bank ld (BankSwitch), a ld hl, AimingTable ; set base address for aiming table ld a, (PlayerY+1) ; get player y position sub e ; subtract enemy y position jr nc, + ; is player below enemy? neg ; no? then invert distance inc h ; change table +: and %11110000 ; extract higher nibble ld l, a ; store in index byte ld a, (PlayerX+1) ; get player x position sub d ; subtract enemy y position jr nc, + ; is player right of enemy? neg ; no? then invert distance inc h ; change table inc h +: rra ; rotate distance into lower nibble rra rra rra and %00001111 ; extract lower nibble or l ; combine with higher nibble from earlier ld l, a ; put result back in index byte ld a, (hl) ; get direction (0-63) from aiming table ret .ends When it comes to updating the bullet, I just use the direction value to access a table of 64 pairs of 16-bit values representing the x and y speeds in 8.8 fixed point numbers and fetch from there what I have to add to the current bullet position. If you need different speeds, just prepare different tables to access. 64 possible directions have always been accurate enough for me, but actually you can blow all your 64 directions on two tables instead of four since the player is always below the enemy, thus their aim being potentially even better. Long story short: I strongly suggest precalculating as much as possible. |
|
|
Posted: Sat May 04, 2024 8:05 am |
Ah sorry I misread your post, you have 16 directions per quadrant. I suppose a first optimisation is to pre-calculate the 3 difficulty velocity tables instead of multiplying those from SIN/COS at runtime. I considered cutting down the velocity table too as enemies only fire south on the Y-axis but I might need a homing shot for the player later on. Thanks for your input. |
|
|
Posted: Sat May 04, 2024 12:01 pm |
note that create_next_vx = SIN_LUT[atan_two + 64] << 2;
can be troublesome, you better do create_next_vy = SIN_LUT[atan_two] << 2; create_next_vy = SIN_LUT[atan_two] << 2;
atan_two += 64; create_next_vx = SIN_LUT[atan_two] << 2; |
|
|
Posted: Mon May 06, 2024 10:58 am |
Just continuing updates on the game from the devkit thread here.
The switch to code banking failed after trying to refactor for a couple of days, so I've decided to stick with what I've got and switch banks manually if needed. There seems to be little difference other than having to manage which code bank is active (above banks 0 and 1), unless there are other differences I'm not aware of? It shouldn't impact the game's design as most of the main systems are complete and it's just a case of adding more data (enemy events, stage events, gfx...) to finish the game. |
|
|
Posted: Mon May 06, 2024 1:17 pm |
If you switch banks 'manually' then your code will be paged in slot 2 (that is at address 0x8000) and this means that code can't page any asset (because it would remove itself from the addressable space the moment it does that) so the code you place there has this limitation. | |
|
Posted: Mon May 06, 2024 1:25 pm |
Ah yea this is one limitation I noticed. As far as I can tell, I either need to include the assets in the banked code file as well, or call the asset loading function from bank 0 or 1 where it can page the assets to bank 2 to load. At the moment I'm choosing to load assets from a function in bank 0 or 1, so I can keep using asset2banks easily and don't need to copy them to my banked code file. It still has saved me a lot of bytes by banking a whole module, I just need to load assets from 0 or 1. |
|
|
Posted: Mon May 06, 2024 8:19 pm |
Worn out from bug fixing but we've got a stable build again and I've been able to add a few more enemy patterns today.
Decided to do a little more gfx work polishing this boss too. |
|
|
Posted: Sat May 11, 2024 12:30 pm |
Added player dash on double tapping move for a quick escape.
You also spawn score bonuses by dashing through enemy bullets, it's harder than it looks. It needs more testing but I think with the right settings it won't be spammed to move everwhere (famous last words?) |
|
Goto page Previous 1, 2 |