Goplanes

[KanedaFr]

We really want to add a nice and advanced sprite support in SGDK. Something that permit to handle animations, collisions, sprites chains...
I know Kaneda is working on something, i have also some ideas about that but that require many time to design and implement.

yep...I had something for anim and sprite chains (big sprite ?)
for these one, my problem is memory : if I add stuff like this, even a game with single sprite will consume too much memory...

nothing for collision because every game need a different / optimized library
I tried some years ago to make a tool for collision but it wasn't a success because it used simple collide box which wasn't enought

[Stef]

Did you fixed your problem with the window ?

Nope

Ok, i will make some tests with a bottom localized window in a small example and try to sort out the problem.

That's exactly why I keep posting I've found working on the Genesis so much easier and straightforward to work with than when I spent a summer trying NES programming. With the NES, I got stuck easily into the platform's quirks and idiosyncrasies and can ever get into actual game building. Seeing that there are so few people working on Genesis homebrew, I want to make it easier for them to get started. Making Genesis games in C is really great and I wouldn't have gotten this far if it weren't for the SGDK.

Glad to heard that I did not expect genesis to be simpler to develop than NES... and your feedback help in improving SGDK too (your window problem is a good example) !

The killer is making the tools. If ever I wanted to create a complex-sprite editor (and I'd sure like to) It'll easily double my development time. Goplanes development is slow enough as it is

Indeed, developing tools require effort and time...
Ideally SGDK should provide some more advanced tools to handle large level background with easy vertical and horizontal scrolling. And same goes for sprites...

[Stef]

We really want to add a nice and advanced sprite support in SGDK. Something that permit to handle animations, collisions, sprites chains...
I know Kaneda is working on something, i have also some ideas about that but that require many time to design and implement.

yep...I had something for anim and sprite chains (big sprite ?)
for these one, my problem is memory : if I add stuff like this, even a game with single sprite will consume too much memory...

nothing for collision because every game need a different / optimized library
I tried some years ago to make a tool for collision but it wasn't a success because it used simple collide box which wasn't enought

At least we could provide simple collide box (or circle based collision) just to have something. And of course, having chains sprite and animation facilities. I do not understand the memory problem you experienced, the sprite patterns always stay in ROM, basically you only need to store some references but i may miss some points

[KanedaFr]

when I talk of memory problem, I talk about memory used for nothing

Typically, I have a my own animated sprite lib and my own sprite handling which add dynamically link to SGDK's one
Imagine I merge anim + sprite + SGDK sprite in one Sprite lib...
each sprite would use more memory, even if collide and anim aren't needed...

Plus come the problem of the data... it's a pain to fill by hand every info needed for anim and collide, a visual editor IS needed
It's why I actually handle anim perfectly (for my need) using ANI format but not collide... because I don't know how to define the collide box using a useful tool (and I don't make public tools anymore)


for large level bg, it's easier....
my code is based on mappy (MAP on genres) but I could adapt it to handle a standard map struct
width
height
tiles[width][height]

or I could simply share any missing GenRes relatif code...and do as you like

[djcouchycouch]

Ok, i will make some tests with a bottom localized window in a small example and try to sort out the problem.

My comment was about the changes I had originally made locally to fix the problem. I have not tried your suggested fix yet.

I did not expect genesis to be simpler to develop than NES...

The reason is because I'm totally not an assembly programmer. For me, going from C++ to C is much, much easier than going from C++ to 6502 assembly programming. With NES programming, I got stuck spending too much time trying to do basic things to do anything fun. So it got frustrating. The 68k CPU is much faster and more more powerful so it's a lot more forgiving. I don't have to super optimize absolutely everything to get decent performance. I just have to be careful not to do anything obviously slow. So I get to do old-school console programming but still have some conveniences.

[Stef]

when I talk of memory problem, I talk about memory used for nothing

Typically, I have a my own animated sprite lib and my own sprite handling which add dynamically link to SGDK's one
Imagine I merge anim + sprite + SGDK sprite in one Sprite lib...
each sprite would use more memory, even if collide and anim aren't needed...

Indeed that would consume more memory and also produces a bit of inefficient code by doing extra copies...
Maybe i have to think about directly integrate a high level sprites engine on the low level with sprites hardware to avoid, as much as possible some redundancies.

Plus come the problem of the data... it's a pain to fill by hand every info needed for anim and collide, a visual editor IS needed.
It's why I actually handle anim perfectly (for my need) using ANI format but not collide... because I don't know how to define the collide box using a useful tool (and I don't make public tools anymore)

Indeed the sprite engine need to be filled with a visual tool :p
And it would be great to have the collision information included but that would require to develop our own tool...

for large level bg, it's easier....
my code is based on mappy (MAP on genres) but I could adapt it to handle a standard map struct
width
height
tiles[width][height]

or I could simply share any missing GenRes relatif code...and do as you like

Well i just missed that genres demo :p
I never needed it so i have to admit that i never really look into that.
At least now i know there is something for that

[Stef]

My comment was about the changes I had originally made locally to fix the problem. I have not tried your suggested fix yet.

Ok, i was refering this part :

I tried to set the status bar at the bottom, using the new memory addresses suggested by Stef, but I can't get it to work. I still have the same problem as originally. No idea why.

So as you manually changed the address i will try to do a small demo with both plan filled and plan set to bottom (as the problem is here : having a window at bottom without corrupting data).

I'll wait until the next version of SGDK comes out. Stef, any idea when that will be?

Oups missed that ! sorry i don't have any date as i want to always do release when i am in a stable state and when there are worthy news
I will try to not be too long for the next version, still you can check sources changes directly from the repository :

http://code.google.com/p/sgdk/source/br ... vn%2Ftrunk

The reason is because I'm totally not an assembly programmer. For me, going from C++ to C is much, much easier than going from C++ to 6502 assembly programming. With NES programming, I got stuck spending too much time trying to do basic things to do anything fun. So it got frustrating. The 68k CPU is much faster and more more powerful so it's a lot more forgiving. I don't have to super optimize absolutely everything to get decent performance. I just have to be careful not to do anything obviously slow. So I get to do old-school console programming but still have some conveniences.

C language was definitely a good choice to define SGDK basis lot of people are scared by assembly programming... I'm not too familiar with 68k assembly and it's a pain for me too when i need to use it :p Glad that 68k is fast enough so we can keep C in almost case.

[djcouchycouch]

I will try to not be too long for the next version, still you can check sources changes directly from the repository :

http://code.google.com/p/sgdk/source/br ... vn%2Ftrunk

I often check out the repository. But unless I'm looking at the wrong thing, the last commit was on Sep 20, 2012?

http://code.google.com/p/sgdk/source/list

The changes you did for the Window plane haven't been committed yet?

[djcouchycouch]

C language was definitely a good choice to define SGDK basis lot of people are scared by assembly programming... I'm not too familiar with 68k assembly and it's a pain for me too when i need to use it :p Glad that 68k is fast enough so we can keep C in almost case.

Maybe once SGDK matures it might be a good idea to do pass where certain important functions are converted to assembler. (if it's not the case already) I think it's important to have a C interface for users, but internally I'd lean towards getting it to run as fast as possible.

But so far I'm pretty satisfied with its current performance.

[Stef]

I will try to not be too long for the next version, still you can check sources changes directly from the repository :

http://code.google.com/p/sgdk/source/br ... vn%2Ftrunk

I often check out the repository. But unless I'm looking at the wrong thing, the last commit was on Sep 20, 2012?

http://code.google.com/p/sgdk/source/list

The changes you did for the Window plane haven't been committed yet?

True.. i have to admit i do not commit a lot more that i am doing new releases of SGDK so that won't really help here.
I should commit on a regular basis, that could help users who want to test last changes and beta test stuff !
Anyway as i mentioned in another post, the only change i made for the window is the WPLAN define and the vdp registers initialization (i now use the 'define' instead of direct values for plan addresses).

Maybe once SGDK matures it might be a good idea to do pass where certain important functions are converted to assembler. (if it's not the case already) I think it's important to have a C interface for users, but internally I'd lean towards getting it to run as fast as possible.

Of course that make sense, actually for critical parts i try to use optimized C code when we don't have assembly code. And more and more convert some methods to assembly when needed. The 68k is maybe faster than a 6502 but still it is a very old cpu and we cannot waste cycles

But so far I'm pretty satisfied with its current performance.

Thanks I think it is also important to keep the code "readable" as users would have a look at it to learn. The hard part is to find the good compromise between readability and performance, so far, SGDK is not that bad for that Of course users feedback is important, i remember someone mentioned poor performance of setPalette(..) methods which should be fast... i switched to ASM code and now they should be fast.

[neologix]

question: is it possible to make the coin sprite look like the one below?



mostly just a simple color edit, but i gather such a thing would also go along w/changing the general art style to be a bit less solid.

[djcouchycouch]

question: is it possible to make the coin sprite look like the one below?



mostly just a simple color edit, but i gather such a thing would also go along w/changing the general art style to be a bit less solid.

Thanks for the suggestion.

I had originally tried making sprites without the blue border, but they just didn't pop out as much. Goplanes is a game that has the player constantly moving so I want to make objects and obstacles clear to them. That said, I'm not super crazy about having a blue border around everything either. So for the short term I won't be changing it, but I'm fully aware that it needs work.

[djcouchycouch]

Small update.

Fixed goplanes vertical scrolling corruption bug. Size of data to copy: 62 bytes. Size of destination buffer: 60 bytes. Whoops.

[djcouchycouch]

- New status bar. While not as nice as the floating UI icons from the previous versions, it takes much less CPU to compute. I might revisit this.

Sure enough, as soon as I posted the video last week I started really disliking the status bar. It felt like it "cut off" the sky, not making it look open enough for my tastes. So I just spent a few hours trying to optimize the old hud. Got performance using the old hud close enough to the status bar. So I've gone back to the old hud.

Now I feel bad about bugging Stef about the Window plane stuff

[djcouchycouch]

Minor thing: added new options in the debug menu for invincibility, wait for vsync and show fps counter.