Page 2 of 4
Posted: Tue Jan 07, 2014 7:11 am
by r57shell
I have GEMS sound driver research in progress.
I don't know anything about copyrights... But, I can help you integrate DefleMask music via GEMS sound driver if you want.
I didn't make any steps further for several months. But I would like to continue... I just need something to work with.

Posted: Tue Jan 07, 2014 2:38 pm
by camous
Thanks, but I think I'll stick to the VGM driver. Trying to keep things simple on this project.
I also think that GEMS has a bad rep.
Posted: Wed Jan 08, 2014 12:17 am
by camous
About Genres and .ani files.
I cannot find any documentation on how importing these is handled. There is a .bin file in the out folder which demonstrates a felicia animation being used but there is no accompanying source code.
Am I not looking in the right place?
Posted: Wed Jan 08, 2014 11:08 am
by TechnoZealot
For music I much prefer Shiru's VGM Music Maker over Deflemask, but I am starting to try to learn Deflemask. Beware that VGM Music Maker, while in my opinion easier to use, mainly exports VGMs of version 1.50, (although it can do v.160, but I haven't really gotten it to work right).
Also @Kubilus1, on a sidenote, will the new VGM player support VGM v1.50 files without the 0x9x opcodes for streaming?
I took a look at some SDCC sources for your original VGM driver that you posted online and compiled them in Windows with the intent of making it v1.50-compatible, using the makefile --stack-loc 0x1fff --data-loc 0xfff arguments, but the driver produced failed to load a sample VGM.
I have had a number of MD chiptune artists ask me to try to get VGM Music Maker-compatible VGM import working with SGDK, since many are reluctant to switch to Deflemask so I have been working along these lines for a bit.
@camous:
For handling sprite animations, if you are loading an animation that will fit in a single sprite, you can load a vertical spritestrip of arbitrary length using GenRes by using the SPRITE definition and giving it the width and height of one frame in pixels, so like for example in a game I am working on, I load a small player spritestrip with frames arranged vertically with the first at the top like this in my resource.rc:
SPRITE nakht "data/nakht.bmp" 16 32
Then in-code, the genresSprites struct GenRes generates for my character has a field called count, which lets me know how many frames are in the animation.
Hope this helps a bit and best of luck!

Posted: Wed Jan 08, 2014 11:13 am
by TechnoZealot
Just realized I wasn't very clear about how to use GenRes and stuff.
Basically, after you have put your resources in the resource.rc file for GenRes to load (and make sure you do a new line at the end or it will not know to read the last line you put in... VERY IMPORTANT!) to load the struct GenRes has created, I simply do the following:
Code: Select all
...
#include <genres.h>
...
extern struct genresSprites nakht;
...
//I can then access variables within like load the palette for nakht like this:
VDP_setPalette(PAL0,nakht.pal);
//I can get the number of frames like this and then do some math with the frame I am on and the count with the tiles pointer to switch what frame I am looking at.
u16 numberOfFrames = nakht.count;
Here are the fields GenRes stores in the genresSprites struct (taken from genres.h):
Code: Select all
//SPRITES
struct genresSprites
{
u16 *pal; //pointer to pal data
u32 **sprites; //pointer to sprites data
u16 count; //nb sprites
u16 width; //width of each sprite in pixels
u16 height; //height of each sprite in pixels
u16 size; //since we use width/height in pixel, useful info on sprite size
//TODO : size is not SGDK compliant, you need to use size>>8
};
Posted: Wed Jan 08, 2014 11:17 am
by camous
Yeah, I kind of figured about using a bitmap to load max 32 pixel dimension animations.
There are two problems with that though. The sprites animations I want to load are over 32 pixels in height. Furthermore doing it that way does not get you timing information which forces you to hard code that manually.
Using bitmap sheets is best reserved for loading tiles I think.
Posted: Wed Jan 08, 2014 1:59 pm
by KanedaFr
you can export a .ANI from GGale
for bigger than 32x32 sprites, you have to handle it yourself (my lib isn't still public)
Posted: Wed Jan 08, 2014 2:50 pm
by camous
Yeah I know how to export ani. I just cannot find amy information on in which form that ani is imported into my project.
If you could release the source code for the ani example where you imort the felicia animation I could figure it out on my own.
By the way, that felicia ani in the example is 96x96, much larger than 32x32.
Posted: Wed Jan 08, 2014 4:07 pm
by kubilus1
Also @Kubilus1, on a sidenote, will the new VGM player support VGM v1.50 files without the 0x9x opcodes for streaming?
@TechnoZealot. Yes! v1.50 (0x8n) style PCM is a feature of the updated VGM driver I am working on! So far this will be limited to 8khz or lower samples.
However, there is still a big advantage of the v1.6 style PCM samples, that being a *much* smaller file size. I was working on a v1.5 to v1.6 converter, if there is any interest in it, I'll finish it up and post it shortly.
I took a look at some SDCC sources for your original VGM driver that you posted online and compiled them in Windows with the intent of making it v1.50-compatible, using the makefile --stack-loc 0x1fff --data-loc 0xfff arguments, but the driver produced failed to load a sample VGM.
It could be the version of sdcc. The original driver was compiled with 2.9.0 I believe (from memory) The new one will use the 3.x SDCC. (If I release a third version, it will probably be pure assembler.)
Also, with SDCC, you must hack the crt0.s file it uses to point the stack to the correct location and then tell it to use your crt0.o.
Posted: Wed Jan 08, 2014 4:41 pm
by Stef
About resources stuff, the next version of SGDK will add some facilities to deal with sprites. Basically you will be able to handle them from a simple grid image (where each cell is a sprite and a row is a complete animation).
It needs a bit more of work before being released but i hope that will help... it is also very similar to Genres, it is a bit sad because i almost duplicated all the work than Kaneda already done :-/ But at some point i wanted to have a tool which can used on unix system too (i provide sources and i don't use dll) and also have a bit more of flexibility in some structures (and maybe closer to some internals SGDK stuff).
Posted: Wed Jan 08, 2014 5:07 pm
by camous
Is there an ETA on the next version of SGDK? I have a feeling that once I get started on this stuff I am going be very reluctant to switch it out for something else halfway through.
That is why I want to start on a solid foundation. Changes at a later stage are always a source of trouble in bigger projects.
Posted: Wed Jan 08, 2014 5:51 pm
by KanedaFr
@stef : I somehow became used to it. My tools are not used or reinvented.
It's mainly why there is no more update nor new tools : it takes too much times too polish a tool for everyone to use. I now make tools for myself and use the spare time to "use" them

Posted: Wed Jan 08, 2014 7:14 pm
by kubilus1
But at some point i wanted to have a tool which can used on unix system too
Awesome, us *nix folks appreciate the tools. I started to port Genres to Linux at some point and got pretty far along, before I decided to find other solutions.
Posted: Wed Jan 08, 2014 8:23 pm
by Stef
KanedaFr wrote:@stef : I somehow became used to it. My tools are not used or reinvented.
It's mainly why there is no more update nor new tools : it takes too much times too polish a tool for everyone to use. I now make tools for myself and use the spare time to "use" them

I think more people than you think use genres, i used it for a long time, i even did (unreleased) plugins for it ! But at some point i was stuck with some limitations, for instance i wanted to have .h generation support hich is not possible with GenRes, also i really wanted to make tools available to unix users as they become more and more presents

As you say, it is pretty difficult to do a tool generic enough for everyone. I tried to do something good enough but i know that it won't satisfy everyone as it is just impossible

Posted: Wed Jan 08, 2014 8:25 pm
by Stef
camous wrote:Is there an ETA on the next version of SGDK? I have a feeling that once I get started on this stuff I am going be very reluctant to switch it out for something else halfway through.
That is why I want to start on a solid foundation. Changes at a later stage are always a source of trouble in bigger projects.
Difficult to say but i really want to deliver that quickly, maybe in 1 week or 2 but that will be a preliminary version. Then i will improve tools with time...