|
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 |
---|---|
|
![]() |
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. |
|
![]() ![]() ![]() |
|
|
![]() |
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. |
|
![]() ![]() ![]() |
|
|
![]() |
Wow, it looks really great now! | |
![]() ![]() |
|
|
![]() |
it's so cool !
Can't wait to see the rest. |
|
![]() ![]() |
|
|
![]() |
Thanks!
Another work in progress boss. |
|
![]() ![]() ![]() |
|
|
![]() |
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. |
|
![]() ![]() ![]() |
|
|
![]() |
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. |
|
![]() ![]() ![]() |
|
|
![]() |
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. |
|
![]() ![]() ![]() |
|
|
![]() |
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. | |
![]() ![]() |
|
|
![]() |
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. |
|
![]() ![]() ![]() |
|
|
![]() |
Thanks Aranya! |
|
![]() ![]() ![]() |
|
|
![]() |
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. |
|
![]() ![]() ![]() |
|
|
![]() |
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. |
|
![]() ![]() |
|
|
![]() |
[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. |
|
![]() ![]() ![]() |
|
|
![]() |
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 :) |
|
![]() ![]() |
|
|
![]() |
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. |
|
![]() ![]() ![]() |
|
|
![]() |
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... |
|
![]() ![]() ![]() |
|
|
![]() |
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.
|
|
![]() ![]() ![]() |
|
|
![]() |
Gorgeous looking game, much like your last game. The palette really pops. Very nice job on all your designs. | |
![]() ![]() |
|
|
![]() |
Have been following you on Twitter!!! Awesome game...crossing my fingers for a physical release. Keep up the good work!!! |
|
![]() ![]() |
|
|
![]() |
Thanks guys!
I'm hoping for a physical release too, but just focussing on finishing the game for now. |
|
![]() ![]() ![]() |
|
|
![]() |
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. |
|
![]() ![]() |
|
|
![]() |
Thanks, yes plenty of surprises still left to show! And the soundtrack by Crisps, which takes about half the ROM! |
|
![]() ![]() ![]() |
|
|
![]() |
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. |
|
![]() ![]() ![]() |
|
|
![]() |
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. |
|
![]() ![]() |
|
|
![]() |
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! |
|
![]() ![]() ![]() |
|
|
![]() |
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. | |
![]() ![]() ![]() |
|
|
![]() |
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. |
|
![]() ![]() |
|
|
![]() |
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. |
|
![]() ![]() ![]() |
|
|
![]() |
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; |
|
![]() ![]() ![]() |
|
|
![]() |
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. |
|
![]() ![]() ![]() |
|
|
![]() |
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. | |
![]() ![]() ![]() |
|
|
![]() |
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. |
|
![]() ![]() ![]() |
|
|
![]() |
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. |
|
![]() ![]() ![]() |
|
|
![]() |
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 |