Submarine Shooter Project (NEO GEO MVS development) - Page 2

Great, to read that an update of the lib will be available soon. I am looking forward to it .
Thank you for your efforts!

I have drawn a new explosion animation (28 frames) and a new explosion of the enemy submarines (12 frames) and implemented them into
the game. The "old" DATlib was not fast enough to update all the animations and I had massive slowdowns.

So the update came at the perfect moment for me and after adding the new DATlib 0.1 to my dev kit the game was running fluid. The improved
update speed of animated graphics is just awesome THX HPman

In the following video are used 41 animations all the time (preloaded off-screen or animated on-screen):

- 15 enemy torpedos (29 frames)
- 10 enemy submarines (12 frames)
- 10 big explosions (28 frames)
- 5 player torpedos (29 frames)
- 1 player submarine (2 frames)

I have found a little bug (?) or strange behavior of animated sprites in the new DATlib 0.1 which was not present in the previous version.
When the main loop is reloaded all animations get resized to a width of only 1 tile if they use the same animation frame.

Like in the following picture:


I have solved this problem by loading a different animation frame in the first cycle of the re-loaded game loop. For instance, if
the last animation in the first game loop was "IDLE", I set it to "RESET" in the first cycle of the reloaded game loop and then back
to "IDLE" in the second cycle.

Can you post minimal code to reproduce issue, as well as fixed code? I'll look into it.

Nice art and animations on that last demo.

It looks the problem is caused by the "clearSprites(1, 381)" function - maybe I use it in a wrong way. I will post a code demo soon.

Ok, I have removed all irrelevant stuff and here is the code. If you want I would also upload the ROM files and the graphic.
#include <stdio.h> #include <stdlib.h> #include <task.h> #include <input.h> #include <DATlib.h> #include "sound.h" #include "externs.h" typedef struct bkp_ram_info { WORD debug_dips; BYTE stuff[254]; } bkp_ram_info; bkp_ram_info bkp_data; BYTE p1,p2,ps,p1e,p2e; void game() { int spawn_enemy=0; Scroller scroll1, scroll2, scroll3, scroll4; Picture pict1, pict2, pict3, pict4; aSprite enemy_subm1; volMEMWORD(0x400002)=0xffff; //debug text white volMEMWORD(0x401ffe)=0x7bbb; //BG color LSPCmode=0x900; initGfx(); clearFixLayer(); clearSprites(1, 381); aSpriteInit(&enemy_subm1,&enemy_subm_spr, 280, 26, 350, 50, ENEMY_SUBM_SPR_ANIM_NORMAL, FLIP_NONE); palJobPut(26, enemy_subm_spr_Palettes.palCount, enemy_subm_spr_Palettes.data); SCClose(); do{ wait_vblank(); fixPrintf(2,2,0,0,"Game loop - Press D for Game Over"); p1=volMEMBYTE(P1_CURRENT); ps=volMEMBYTE(PS_CURRENT); if(spawn_enemy==0) { spawn_enemy=1; aSpriteSetAnim(&enemy_subm1,ENEMY_SUBM_SPR_ANIM_NORMAL); aSpriteSetPos(&enemy_subm1, 130, 50); aSpriteAnimate(&enemy_subm1); } SCClose(); }while(!(p1&JOY_D)); } void gameOver() { volMEMWORD(0x400002)=0xffff; //debug text white volMEMWORD(0x401ffe)=0x7bbb; //BG color LSPCmode=0x900; initGfx(); clearFixLayer(); clearSprites(1, 381); SCClose(); do { wait_vblank(); p1=volMEMBYTE(P1_CURRENT); p2=volMEMBYTE(P2_CURRENT); ps=volMEMBYTE(PS_CURRENT); fixPrintf(15,14,0,0,"Game Over"); fixPrintf(14,16,0,0,"Press START"); SCClose(); }while(!(ps&P1_START)); } int main(void) { volMEMBYTE(0x10fd80)=0x80; // used for CD-compiling while(1){ game(); gameOver(); } }

Ok, found the issue.
aSpriteInit() requires an additional field clear, because as we are basically always running the same code over and over, enemy_subm1 values are not wiped. So aSpriteAnimate() thinks we already loaded frame.

Anyway quick fix for current release, do a enemy_subm1.currentFrame=0; before aSpriteInit.

Or add a macro to avoid editing code upon fix:#define aSpriteInit(a,b,c,d,e,f,g,h) {*a.currentFrame=0;aSpriteInit(a,b,c,d,e,f,g,h);}

Perfect, thanks for solving this issue in the middle of the night

Because the new DATlib 0.1 supports dark bit colors now, I wanted to figure out which RGB-255 color will be translated to which Neo-Geo RGB-63 color code by the "buildchar.exe".
The following color chart is the result of my research. Any color value has been double checked with the "palettes.s" file and Furrtek's NGPG palette tool (ngpg01.exe).
I have assigned all RGB-255 values to the corresponding RGB-63 colors values (except of color 1 ($0000), pure black with dark-bit off) and hope this color chart will be useful for other developers.

The following table contains all unique (green) RGB-255 color values the Neo-Geo is able to display. There is a quite big gap between color #31 (RGB 117) and color #32 (RGB 136)
but on the real system (NG CD) it does not look that big. It seems that the MAME resistor values are not 100% correct.

HPMAN, if you want, you can download a demo CD with this graphic and test it by yourself: http://www.neohomebrew.com/forum-pics/color-test-cd.rar

Yesterday I wanted to optimize the color palette of the water in the background and I modified the values for a greenish-blue gradient. I have used only even RGB 63 color numbers (00, 02, 04, 06 ...) with
the RGB values of the new DATlib 0.1. Although I was using consistent color number steps, the gradient in the original image looks quite bad (because of the inconsistent RGB values).
Particularly color number #15 does not fit into the gradient. When comparing the following pictures, please pay attention to this color to see the differences.

After that I converted the image with buildchar.exe to the graphic rom and tested it on several emulators and the real system (MV1FZS).

The results are:

MameUI32 0.141u2 emulates the colors almost the same like in the original image and the gradient looks inconsistent
Mame32 0.90u1 shows the perfect world - a consistent gradient which looks even better than on the real system (I wish the real system would really output the colors in this way...)
NeoCD/SDL 0.3.1 emulates the colors close to reality - it looks only slightly inconsistent almost like on the real system

I would suggest better to use the RGB color values of NeoCD/SDL 0.3.1 instead of the values of MameUI32 for translating the colors.

Here are the screenshots / photos:

Inspired by the "240p test suite" (http://junkerhq.net/xrgb/index.php/240p_test_suite), I have made a little tool with 11 test patterns for testing the video output of Neo Geo systems.
The tool is intended for adjusting the picture of CRT monitors and for CMVS builders who want to test their modded arcade boards.

Particularly interesting is the "Color Bars" pattern which contains any RGB level of the base colors red, green, blue and white.

The tool is available for Neo Geo CD, MVS and AES and can be downloaded from my website:
http://www.neohomebrew.com/neo-geo-monitor-test.php

Here is a short video of the tool:

Hi, any update on this, or is it just a demo that's no longer updated?

just because i am a nerd, it's not the good logo (the neogeo CD version is different)

kuk (./44) :
just because i am a nerd, it's not the good logo (the neogeo CD version is different)

Sorry was this a reply to me? Think something got lost in translation, not sure what the good logo is?! are you saying the demo is not for the NGCD, just MVS?

OngaDragoon Sorry no (i not see your post...) i answer to NeoHomeBrew and the Neo Geo logo on the TV

The submarine shooter project is "on hold" currently, want to finish Hypernoid first.
Yes, the logo is not the NGCD logo - I have used it because I like the classic logo a bit more

NeoHomeBrew (./47) :
The submarine shooter project is "on hold" currently, want to finish Hypernoid first.

OK no worries, best to concentrate on one project at a time. Hope it gets resurrected one day.

How to Make Shooting Games


I can do some basic actions with DATlib 0.2. I studied Sebastian Mihai's NEO THUNDER for a while, but my bullets were always bad.


Can a big man help me? Thank you very much.