SpritesMind.Net

So far it's been going great with SGDK, from someone who does not know how to code with C. But here is just some suggestions i thought to make it a little easier for me, the programming noob (artist)

1.Code snippets in the doc.

Sometimes i need code snippets to see how to actually use these functions provided in the headers. Like the window thing.
I have no idea how to use that, but i plan to post about it....

2.Completed workflow tools for SGDK, like a map editor, dialog editor for conversations, and a sprite collision editor for hitboxes (fighting game etc).

I'm currently putting in manual values for collision code into my project.... I would like a visual system. I have no idea how to do dialog boxes, where i could use import from a text document of some kind. The hitboxes i could probably figure out, but the manual stuff is going to be a pain with more then 2 characters on screen.

3.Ran out of things to say, carry on.

#2 is asking for a full blown game engine, SGDK is just a framework o.O (while I can see it as feasible, it should be its own thing, possibly built on top of SGDK, but not in SGDK itself).

Also window has the "what part of the screen will it show up" issue =P (when setting both directions) S/H is even worse, I mean it's trivial once you know the rules, but I have yet to see anybody explaining it in an understandable way (in short: default brightness is based on layer priority, then two colors in sprites can override this)

Sik wrote:#2 is asking for a full blown game engine, SGDK is just a framework o.O (while I can see it as feasible, it should be its own thing, possibly built on top of SGDK, but not in SGDK itself).

Also window has the "what part of the screen will it show up" issue =P (when setting both directions) S/H is even worse, I mean it's trivial once you know the rules, but I have yet to see anybody explaining it in an understandable way (in short: default brightness is based on layer priority, then two colors in sprites can override this)

Oh, not demanding just suggesting. I know it takes time to do something like that, but i will be here to cheer people on if anyone does get started! 8P

Ah i see. Perhaps i will just stick to the black bottom for now then.

Thanks for your feedback
Code snippets is why "sample" folder exist but i agree it would be nice to have it directly in documentation sometime

Of course it would be nice to have tools for that and that is part of "my originals plans": having something to build the SpriteDefinition structure graphically and in a flexible way, same to design Level Map (Map structure, which will change in future i guess)... but as Sik said, that might be really difficult to do something generic enough, also that is a lot of work to do on my spare time... I'm writing all tools code in C, so they can be easily compiled for others platforms. Writing complexes graphic tools for Sprite / Level editing will require more advanced programming language (as java), it would be really overkilling to do them in C. But currently, i prefer to focus on SGDK library itself, advanced tools are definitely on a lower priority.

I've found the forum the best place to get the majority of my answers

Stef wrote:Thanks for your feedback
Code snippets is why "sample" folder exist but i agree it would be nice to have it directly in documentation sometime

Of course it would be nice to have tools for that and that is part of "my originals plans": having something to build the SpriteDefinition structure graphically and in a flexible way, same to design Level Map (Map structure, which will change in future i guess)... but as Sik said, that might be really difficult to do something generic enough, also that is a lot of work to do on my spare time... I'm writing all tools code in C, so they can be easily compiled for others platforms. Writing complexes graphic tools for Sprite / Level editing will require more advanced programming language (as java), it would be really overkilling to do them in C. But currently, i prefer to focus on SGDK library itself, advanced tools are definitely on a lower priority.

Yeah i was looking at the code sample folder for the sprites stuff. Just has to be a bare bones code snippet to make it work, and i'm fine with that.

Yeah, the SGDK should be higher priority. I might do something with Construct 2 to output some code in a text file, so i can paste it in Codeblocks for levels. Nothing special, but i'll ask around to make sure it can be as useful as possible for SGDK specific. 8P

If you want to poke around my project here: https://github.com/Mikejmoffitt/LICS you can take a look at how I chose to solve some of these design problems. I had the same problem of unfamiliarity with SGDK's structures and mechanisms for dealing with level layouts, tile mappings, graphics creation, etc. so I've crafted some (crude) tools of my own to fill my own data structures. Right now there is no compression, but the level format is more or less a static header, followed by an object list, then the raw level array which is sized based on height/width information in the header.

The level editor is in the /leveled subdir.

mikejmoffitt wrote:If you want to poke around my project here: https://github.com/Mikejmoffitt/LICS you can take a look at how I chose to solve some of these design problems. I had the same problem of unfamiliarity with SGDK's structures and mechanisms for dealing with level layouts, tile mappings, graphics creation, etc. so I've crafted some (crude) tools of my own to fill my own data structures. Right now there is no compression, but the level format is more or less a static header, followed by an object list, then the raw level array which is sized based on height/width information in the header.

The level editor is in the /leveled subdir.

Cool. I'll take a look at it and see what i can do. Thanks!

Reminds me, I had uploaded the converter script for Dragon Castle to GitHub (see Demos subforum), the original levels are in TMX format (Tiled's), set to CSV.

Don't ask me for much help on that though since my laptop's charger is dead (on a phone right now). When I replace it I'll be of more help.

I have a map editor in progress for my own framework, but it exports as generic binary data so no doubt it would be suitable for SGDK too.

Very old sneak preview: https://www.youtube.com/watch?v=gShxiJxg-sI

It's progressed a hell of a lot further since I recorded that, though. It now has game object support, palette swatches, palette save/load, stamp flipping, batch bitmap import, import direct to stamp, collision tile editor, collision tile painting, direct-to-canvas collision pixel painting, auto terrain generation, and a lot more.

I'm gearing up for a public release, I'll let you know when it happens.

BigEvilCorporation wrote:I have a map editor in progress for my own framework, but it exports as generic binary data so no doubt it would be suitable for SGDK too.

Very old sneak preview: https://www.youtube.com/watch?v=gShxiJxg-sI

It's progressed a hell of a lot further since I recorded that, though. It now has game object support, palette swatches, palette save/load, stamp flipping, batch bitmap import, import direct to stamp, collision tile editor, collision tile painting, direct-to-canvas collision pixel painting, auto terrain generation, and a lot more.

I'm gearing up for a public release, I'll let you know when it happens.

That's looking great. Well you do a tutorial for SGDK specifically? I don't know how to implement it, even if it's compatible with SGDK.

I've never used SGDK myself but I'm sure I can figure something out for you

BigEvilCorporation wrote:I've never used SGDK myself but I'm sure I can figure something out for you

Thanks! 8B