Abyssal Infants. - Page 1

Hi.
I made a game with NGDK.
It is name Abyssal Infants nad it is a port of a game I made for Mega Drive with SGDK.



Right now there is no sound, no menu, no coins etc just the levels of the game.
I can add sounds with the NGFX SoundBuilder but as it looks like I cannot pass the 2mb for v1.


You can find it at:
https://kakoeimon.itch.io/abyssal-infants

The NeoGeo version is the ssideki.zip (runs on MAME)

and the .neo file probably running with NeoSD or Mister but I haven't tested this as do not have any of those.

Please inform me if the .neo file does not work and if so how I can create one from the ssideki.zip

Also I would love to know if the problems of the greenish screen when running a NeoGeo game created with NGDK still exists.

Thanks.

Hi,

I already saw your project on Twitter, but glad you came here to present it
I will try to test the game, but I lack time...

hi there,
a nice and promising project (I hope sound will come soon ) - I tested it with my NeoSD.
works on real hardware but unfortunately very heavy tearing in the upper screen area and the whole screen has a green tint. this is a not emulated 'feature'... the reason for this green is the used palette (or the created palette you use) which sets a value other than 0x8000 (dark black) for the color #0, this color is taken as reference color and therefore has an effect on the color output.

Hi, thanks for testing.
To be clear to me, you were able to run the .neo file? I am asking cause I previously had a .neo file up that was made differently and a user reported that it was not working.

From what you are saying for the colors I guess that the problem comes from the convertion tools used from NGDK.
Good news is that those tools were writen by the same person who wrote NGDK so probably he will be able to fix them.
Bad news are that he does not have a NeoSd to make tests.

I will inform him of your report.

Sound is already added thanks to your answer in the thread of your NGFX SoundBuilder, I just have not uploaded this yet. (Hope to uploaded this with sound and without the green).

By the way NGDK is so good that I believe it have the potential to change the course of the NeoGeo homebrew scene.

kakoeimon (./4):...
To be clear to me, you were able to run the .neo file?...

abyssal_infants.neo [CRC32: 37180794]

this NEO file runs via NeoSD on AES... but with the mentioned problems.

kakoeimon (./4) :By the way NGDK is so good that I believe it have the potential to change the course of the NeoGeo homebrew scene.

How ? Why ?

The 1st feature for a good kit/engine/SDK/framework is to have been tested and validated as working properly in real conditions. Other features can be cool, but the priority is having something with the basics working well.

Be sure Im interested by any new amazing tool for the Neo Geo. Currently I use NGDEVKIT. I trust this devkit because with the creator, we spent time (and we still spend) to check that everything work well on real hardware (vblank, timer interrupt, bios sequence, memcard, soft dips, MVS backup ram...).

Same thing fot the NGFXbuilder made by Blastar. It is a very solid and reliable driver/software. That is the 1st thing expected.

This is the github link to NGDK https://github.com/Kannagi/NGDK
There can be found the discord server and the creator is active in answering question.
Also the solution to the problem of green screen by the time Blastar gave more information probably found and fixed.

What I mean is that if we do not help the developers they are not going to find solutions to problems.

Also the upper screen tearing probably is a problem I created in the code of the game. Now fixed.

The problem is that NeoSD and NeoGeo as console or consolized remains expensive.
So in this case as the creator does not have a NeoSD he cannot test the SDK on an actual NeoGeo and he relies on MAME.

I do the same thing.

I have seen NGDevKit but NGDK was more aproachable. I personally believe that user expirience (of any SDK or framework) is of high priority. What I mean is that a higher abstraction makes the expirience better and gives the game designer - coder more freedom to bother with the gameplay coding.

I am uploading now the latest .neo file.

With all the fixxes and with sound (not all the music tracks and in low quility).

Please test.

I know the problem of expensive hardware. I have asked many times Terra***** to do sponsorship and provide some free SD stuffs to developers, but sadly they never replied.

latest NEO file works fine on real hardware (NeoSD @ AES), no more tearing, green tinge fixed, sound works, no slowdowns so far... good job!

Thanks you blastar for testing and reporting. Knowing that it works on a real machine it is huge news for me.

@Kakoeimon Congratulations on your game! Its a great step forward for you and the NGDK too! I was always curious about the green tinge since the original release of NGDK! @Blastar awesome work on solving this mystery!

For what its worth my 2 cents on the avaliable devkits.

It is nice to know that there are some great varieties of dev tools out there. I love seeing what the Devs come up with and how they incorperate their ideas. I find it interesting that NGDK uses Tiled files to compress large maps! NGDevKit looks very interesting as well I love the space harrier style demo totologic made (thats some next level shit in my opinion) very neat would love to try my hand at a style of game in that perspective one day.

DATLib is my personal favorite. Before DATLib I was limited to 15 colors on all my sprites and DATLib really focused not only on utilizing all avaliable colors but tapping into the core functionality the system offers. I had been dabbling in Neo Development before DATLib with the NeoDev SDK and when I found DATLib it changed everything for me. The documentation is a joy to work with and as of now the phenomenal Hypernoid game is a true testament to what can be achieved!

Blastars tools are invaluable on so many levels and they work so well combined with any development environment. Hats off and thanks again.

I owe these devs to use their tools and make something great they and I can be proud of.

I must say at this point my experience is with DATLib and I need to stay the course and actually complete a project with it. Its been said before but a huge thanks to HPMAN for his dynamite tool. I have been playing with it since I got my hands on it and loving every minute of it!

Love and shoutout to all Neo Dev's grinding out their projects pushing themselves and the hardware to the limits. You guys are true inspirations. Keep up the great work.

I now have to play me some Abyssal Infants, Hypernoid and Jump & Run (that split screen concept was freaking nuts BTW)

Thanks MegaShocked.
Maybe the whole thing came out wrong cause I failed to understand how to add graphics in NGDevKit or cause I ignored DATLib all together as it is closed source and I felt not safe to work with it.
Also the license of NGDevKit LGPL3 was something I did not like. I do not know if it is realy a problem.

What made NGDK a good choice for me was the way you compile your resources and the design of the actual SDK.

In NGDK you have a rescompile.txt were you name your resources and compile.bat --res takes care to add the graphics in the roms. Also the whole thing of the SDK (framework?) falls down to a simple Sprite Array that made sense to me cause NeoGeo in graphics is just that. What I relly wanted was a little bit higher abstraction from the actual machine cause learning all this stuff of the hardware to be able to just move a sprite was too frustating to me.

In other words NGDK have a lower entry level, so I do not have to know exacly where the sprites are stored in the rom, neither why we use ssideki.zip. etc.

That's why I was compaining in blastar's NGFX SoundBuilder thread of this forum. Cause ssideki had 2mb for samples and I was making 4mb and 8mb v1 for samples.

With NGDK and NGFX SoundBuilder we have easy tools to make games for the NeoGeo.

I am not saying that those are the best tools but the eisiest.

P.S. NGFX is closed source too, but in the user's code is much less and probably can be replaced easily.

P.S. I hi-jacked the thread of my game... how cool is that?

I'm happy that my SDK works perfectly on real hardware !

It motivates me to continue to improve myself and to be able to manage new things ^^
Thanks to kakiemon who uses my SDK and allows to test it.

For me the abstraction of the hardware seems obligatory, 90% will use the hardware badly, so my vision is that it must be done by experienced people, and that the user focuses on the gameplay, and that is the goal of NGDK, which is almost a full assembler for SDK functions.

Thanks for NGDK once again Kannagi.

Kannagi (./13):I'm happy that my SDK works perfectly on real hardware !

it works on real hardware but there is certainly enough room for improvement!

Me too I would like to say thank you to all people doing great stuffs, demos, kits, tools...

The 2 main reasons why I used NGDEVKIT are:
- it is native Linux sources (I hate Make on Windows)
- no abstraction for the display, I like to experiment my own code and build my own exportation tools because I think it participates to the visual identity of a game. Currently I do only C code, but I expect to code assembly in futur and reach the next level.

I guess they are also 2 good reasons why some people will not like to use NGDEVKIT.

totologic (./16):
- no abstraction for the display, I like to experiment my own code and build my own exportation tools because I think it participates to the visual identity of a game.

I think you missunderstood NGDK's abstraction. There is no abstraction for the display aside from how you create sprites and how you move them and update their tileset etc. How to create palettes.
There are even Background and animation helpers, but I did not used those cause I just have two 512x200 background layers and I just did those with sprites. I haven't used the animation helpers cause that's pretty basic and I had to create animations with a fixed floating point cause the game have a slow down mechanic. (I used SGDK's fx16-fix32 )

I also cannot understand how the tools can participate in the identity of a game.

totologic (./16):
- it is native Linux sources (I hate Make on Windows)

I am on Linux, so NGDK was developed on Linux only, Windows ports were not made by me!

I also cannot understand how the tools can participate in the identity of a game.

What tools do you use to create your art and animation ?

You will have different results if you use Paint, Photoshop, 3ds max, Animate, Spine... And because none of them export directly optimized file assets for the Neo, we must write the relevant tools.

For example, if we take Street Fighter and Mortal Kombat, it is not hard to imagine how different were the tools and methods used to create the characters.

totologic (./19):

I also cannot understand how the tools can participate in the identity of a game.

What tools do you use to create your art and animation ?

You will have different results if you use Paint, Photoshop, 3ds max, Animate, Spine... And because none of them export directly optimized file assets for the Neo, we must write the relevant tools.

For example, if we take Street Fighter and Mortal Kombat, it is not hard to imagine how different were the tools and methods used to create the characters.

Looks like I misunderstood you, cause it seemed to me that you were writing a pixel editor.
I believe that convertion tools can only give limitations and not advancements.

I hope we can standarize (even across SDKs) the way we add graphics and sounds for our games in the roms.
Kannagi had created graphics tools for this and at least the way those tools are used with NGDK is in my opinion the easiest possible way.

Back then games were made by dev teams, in the homebrew scenes two people working on the same project is a luxury.
We have better tools but we lack in man power.

I had a discussion with a MegaDrive dev who was active in the days of the console and he told me that they had SDKs too in the form of routines in assembly. For example the code for animation, collisions, transitions etc was reused in many games, they also had experts working full time on the in house tools.

The knowledge required to do what they did is very wide and without the technical and economical support they had it is almost impossible to be done from only one person. Also if we consider the advancements we have today in game design, the required knowledge is even wider.

My experience after 1 released game on Neo Geo: almost 25% of my time was spent on tools and automation for exporting animations and graphics. Each time I had to rewrite part on my display engine on the Neo Geo side, managing double buffering, priority and memory in different ways, depending if the sprites were used as user interface, character, part of a cinematic....

And I didn't even reach all the possibilities offered by the machine as I didn't use palette animation neither auto-animation feature.

The machine offers a lot of potential in animation, the code part must be driven by the art, not the opposite. That is my point of view. I think that is how innovation can be achieved without upgrading the hardware. That is how the games leveled up in quality between the first and the last games released.

totologic (./21):
The machine offers a lot of potential in animation, the code part must be driven by the art, not the opposite. That is my point of view. I think that is how innovation can be achieved without upgrading the hardware. That is how the games leveled up in quality between the first and the last games released.

And yet in arcade it has always been the opposite, it always aims to make technically impressive games, even if it means being games that are not necessarily interesting.