Finally pushing out a library update.

Biggest changes are the introduction of sprite pools methods and total rework of timer interrupt related code (see raster scroller demo for some fun).

Some of the VRAM update code is more aggressive timing wise, make sure to report issues (if any) on real hardware.

Hopefully nothing broke in the update grin

Version 0.2 updates: ==================== Introduced sprite pools, check documentation. Introduced a new sprite framing tool. Tools related ------------- - Fixed various glitches/craches/file locks across tools. - Buildchar: tool now requires to specify input xml file. Added config options, see doc. This allow to alleviate char processing time by splitting assets into multiple files. - Buildchar: it is now possible to mix auto4 and auto8 tiles on the same file. - Buildchar: when processing sprites, data not used in frames is now ignored. Misc code related ----------------- - Switched draw commands tables addressing mode (from index to pointer). This changes nothing except if you made custom code to write in these tables. - Added draw buffers usage meter (dip 2-3). - Squeezed out some more CPU cycles here and there. - Renamed a few element for consistency: wait_vblank() => waitVBlank() Scroller => scroller Picture => picture - Revamped timer interrupt code: * Runs faster * Should now retain effect on dropped frames. * Now uses the USP register, no more OS writing for you. * Changed data format for rasters info, check doc. * Removed the default raster data tables, allocate your own tables if you use timer interrupt. * Can now updates two values per IRQ trigger. aSprite related --------------- - Fixed issue where aSprite wouldn't initialize properly under certain conditions. - Added aSpriteHide() & aSpriteShow() methods.


Thanks Santa Claus !


Last minute glitch fixed, please redownload the archive if you already picked it up.




Killed another crash with aSpriteInit(), another download for everyone boing


Today is my Lucky Day !! smile


My handle says it all!

I have been working with NeoDev for several years and am very aware of the limitations.
I have been harassing just about anybody I can think of to help me develop tools.

Like a pizza pocket my mind exploded upon reviewing your documentation and watching the YouTube videos!!!!

Thanks so much for all of your efforts. I am going to have to majorly rethink the way I am currently building my projects now but the possibilities are endless.
Full use of colour! Easy Animations! 4 friggin P support!!!!! Sprite Pooling looks super cool have dive into that one! Compressed gfx data.....list goes on man!!!!

You are not HPMAN you are the MAN!



Hello Mega Shocked, could you present your work in a new topic ?
La Neo Geo CD à son site (en tout cas elle essaye...): http://neogeocdworld.info/
Le forum de la Neo Geo sur Yaronet: forums/264

Un petit site sur l'Atari Falcon avec plein de trucs bon pour votre poussin: http://falcon.ti-fr.com/


Hi kuk

My work is not ready for it's own topic yet. I promise as soon as I have something good enough to present I'll make a post happy The Neo is very dear to my heart almost all my free time is spent programming for it! Now that HPMAN has released his kickass toolset I'm most likely going to rework my entire program from scratch. Graphics were not handled efficiently before I had to move past the puzzledp rom to a rom that had a P1 1024 and that was almost full. I was about to move again to a P1 that is 2048!!!! When I say this the backgrounds were all 16 colours and I needed to lay in additional graphics on top of my backgrounds to give more colour to the scene but it was wasting the total number of sprites I was allowed. I was managing but there were a few major issues....

1. I could make a great demo game but had no space to turn it into a full blown game because all graphics were inflating the P1 rom.

Now graphics are compressed and this is a non issue with the HPMAN stuff.

2. All graphics could only use 16 colours. Caused alot of trickery, sprite wasting, additional code and creative thinking.

Now graphics can have the true range of colour and not waste additional sprites!!!!

For those new to developing for the Neo the past and the future are like night and day. This moment in time is historic. The toolset the HPMAN built for us is incredible!

Kuk When I have something worth posting I'll throw up on the forum could be a while though.


I will happy to test your work on my neo geo CD
La Neo Geo CD à son site (en tout cas elle essaye...): http://neogeocdworld.info/
Le forum de la Neo Geo sur Yaronet: forums/264

Un petit site sur l'Atari Falcon avec plein de trucs bon pour votre poussin: http://falcon.ti-fr.com/


Thank you a lot for the new updated library HPMan sun !
I will integrate it to my actual toolset in the next days and will report how it works.
The new spritePool option to display and manage multible sprites is a great improvement!


Now I have added the new DATlib 0.2 to my dev kit and everything is working fine.
My Hypernoid code which was developed with DATlib 0.1 works also well with 0.2 after changing a few things (wait_vblank() to waitVBlank(), Scroller to scroller, Picture to picture).
I was happy to see that this bug is fixed: topics/163491-submarine-shooter-project-neo-geo-mvs-development/2#post-33 and about all the improvements in the Animator / Framer tool.

I have made a hardware test today (Neo Geo MVS MV-2F) with my Hypernoid code (compiled with DATlib 0.2) and I haven't seen any graphical errors.
Then I have tested the new DATlib 0.2 demos and can confirm that the spritePool demo works perfectly and is very fast - there was no difference to the emulation in MAME.
But I have noticed some graphical errors in the two raster effect demos (Picture demo / Scroller demo) and have made photos of it. I am not sure if this is caused by
my CRT monitor, will make a test with a LCD screen in the next days.




I'll set up a a hadware test when I get some time, but raster issue is probably just a bad initial timing value from the demo code (not the lib itself).

Thx for the feedback.


Done a test with the scroller demo, timing issue indeed, base timing of about 14640 worked for me. Can't see far left/far right border on my screen tho.

Thoses things must be adjusted on real hardware anyway, mame is taking some shortcuts with those interrupts.

Not sure yet why my timing calculation is so far off but well, you can make it work adjusting values.


Hi. I'm testing your new Library. And thanks for the sample code.

I have take my old version of the Neo-Geo compiler working with datlib 0.1
I added the lib, include and new software and launch a compilation of the sample. I have warning on the sortSprites() function. And I reload the datlib new new version 0.2
main.c: In function `aSpriteDemo': main.c:196: warning: passing arg 1 of `sortSprites' from incompatible pointer type main.c:277: warning: passing arg 1 of `sortSprites' from incompatible pointer typeline 196 : sortSprites((aSprite*)&drawTable[1],sortSize); line 277 : sortSprites(&drawTable[1],sortSize);
Do you have this warning, I maybe made a mistake. Just to know if it's normal before investigate. I have no error when testing the rom with Mame.


HPMAN confirmed to me that it is a warning linked to the cast inside the function.

So if we add our own "typedef struct", we'll can remove this warning. grin

Sorry for my bad English.



wanted to mess around today with your timer interrupt function. Because default raster tables are removed in DATlib 0.2 could you please
provide the "TIvalues0" and "TIvalues1" tables you have used in your raster demos as a reference?


in sample deùp code included in the archive:
ushort rasterData0[256],rasterData1[256];

Check the rasterScrollDemo() function.


Hi HPMAN, thanks a lot - found it and have updated an older test project (DATlib 0.1) successfully #goltop#