SP1 Engine Update

[Alcoholics Anonymous]

Apologies for posting in English but the last time I tried Spanish translation no one could read it Seeing as the Spanish spectrum community is so active and this forum is an important one for Spanish-speaking people, I thought I would post a note here in addition to the usual English language places.

The SP1 engine for z88dk has been updated yet again. I believe this will be the last time for any API changes. A brief list of what was done:

- Eliminated all declarations required of the user when using the library. It used to be the case that the program would have to declare an id/type association table and a table of sprite draw functions. This was confusing too many people so a new way to do things was found. Now the program doesn't have to do anything at all -- just include sprites/sp1.h and away you go.

- Sprite 'type' used to mean a mixture of sprite flag bits and a sprite draw function identifier. This has been separated so that 'type' only referes to flag bits and the sprite draw function can be specified explicitly by referring to its function address. When creating sprites, one now specifies the address of the draw function to use; this should now make it much clearer how one can use user-defined draw functions as well for special sprites.

- Introduced independent struct_sp1_cs (sprite characters). It is now possible to create struct_sp1_cs sprite characters, of size 8x8 pixels each, that are not attached to any sprite. Their purpose is to be used as foreground graphical elements. Since these are sprite characters, they can be initialized to use any sprite draw function (ie, they can be mask, or, xor, etc) and can exist on any sprite plane. This way individual struct_sp1_cs can be placed at any character position on acreen and can allow sprites to move behind or in front of them. Because the SP1 engine is based on a differential screen drawing algorithm, it only draws portions of the screen that change. Static struct_sp1_cs characters placed on screen do not change and only get drawn when other sprites pass through them. This means their use as foreground elements will not affect game speed appreciably.

The following simple test program shows how a typical SP1 program is written and demonstrates the use of the new independent struct_sp1_cs sprite characters:

http://www.geocities.com/aralbrec/tidbi ... e-test.zip

z88dk is being documented at the z88dk wiki, still under construction but containing much useful information already:

http://www.z88dk.org/wiki

Happy computing!

[na_th_an]

Great news, Alvin. I'm trying to find the time to actually start learning the new version. My only problem is time constraints. I have so little spare time right now that I prefer developing rather than learning the new lib.

I'm planning to follow the huge post you wrote in the WOS forums carefully and see if I can get the grip with the new version, as the new features are awesome and I want them in my next game (specially the ability to "deactivate" character cells so you can create the illusion of sprites moving behind a foreground). The thing is that I don't really know if the latest changes you've made render those explanations and sources "outdated" or inaccurate.

If I had the time and my English was better I'd write a short documentation or a tutorial myself as I am learning. I'll try anyway. Just gimme a pointer: where do I start?

Thanks and keep up the good work. Your library has injected the scene with sheer, new life.

[Alcoholics Anonymous]

My only problem is time constraints. I have so little spare time right now that I prefer developing rather than learning the new lib.

Yeah I know how it goes

I'm planning to follow the huge post you wrote in the WOS forums carefully and see if I can get the grip with the new version, as the new features are awesome and I want them in my next game (specially the ability to "deactivate" character cells so you can create the illusion of sprites moving behind a foreground). The thing is that I don't really know if the latest changes you've made render those explanations and sources "outdated" or inaccurate.

That post is just too huge -- it scares away many people. I will try to do a more compact document in the wiki but I rather dislike writing documentation and prefer to write games / code so it's taking a while to get around to it.

The underlying gist of how the engine works as described in that post is still correct. And the features it describes are still in the current version of SP1. All the programs will still compile and run if the recent changes are taken into account (get rid of the tables you used to have to declare at the top of the file, change the calls to the sprite create functions, move the stack pointer lower in memory; spotting the differences from the sample program in the last post should make it clear) with the exception of the one using a screen$ as background. The current SP1 uses 16-bit tile codes, which can be a character 0-255 as used in splib2 or a memory address where a UDG is stored. So setting up a background screen involves writing 16-bit tile codes that point into a screen for each character square.

If I had the time and my English was better I'd write a short documentation or a tutorial myself as I am learning. I'll try anyway. Just gimme a pointer: where do I start?

Your English is excellent, and a tutorial would be great. If you spend some time understanding how the underlying engine works (a couple of posts near the beginning of that giant thread), the test programs will make a lot of sense and understanding the new features will be a lot easier. The wiki will be more documentation than tutorial so it would be a nice complement.

Where to start... I think the first step is just to use SP1 as an improved splib2. Everything done in splib2 can be done in SP1 and you can even use the same API calls with changes only to the parameters. The improvements you'll see:

- SP1 is slightly faster.

- Code generated will be smaller. The data space required by SP1 is actually larger but I think in large projects the overall size will still be smaller.

- You have complete control over the placement of SP1's data structures in memory, unlike splib2 which just attaches it all to your binary.

- Several annoying things you've had to deal with in splib2 have been removed in SP1 (this is stuff that came up from discussions with you and from looking at your source code, so thanks!): a new sp1_MoveSprPix() function was added to move to pixel coordinates (you used to do all the % and / stuff which made the compiled code ugly), an absolute frame address can now be specified in the move functions (splib2 requires distance from last frame address which complicated matters), new members xthresh and ythresh in the struct_sp1_ss specify the minimum pixel shift required before the last column / last row of the sprite are drawn (you were using a clipping rectangle to stop colours from drawing into a neighbouring char cell caused by the sprite's blank column drawing even when it didn't need to; now the last column is not drawn when not needed).

And then I think you could start experimenting with some of the new features; I'll list some of them here and what their intended uses are:

- Sprites have attribute masks and attributes, intended to help with colour clash. SevenuP supports all of SP1's graphics and attribute formats.

- Dedicated functions sp1_GetSprClrAddr(), sp1_PutSprClr(), sp1_GetSprClr() for quickly colouring sprites. Faster than the old way (and still valid way) involving sp1_IterateSprChar(). Intended to be used inside the game loop.

- Quick animation of background tiles by changing tile graphics associated with a particular character code with sp1_TileArray() and then invalidating a list of affected char cells by iterating over them using sp1_IterateUpdateArr() or sp1_IterateUpdateRect(). Think flickering candles, twinkling stars, waving grass, etc.

- Removal of individual character squares with sp1_RemoveUpdateStruct(). Draw the cell first with SP1, then remove it so that SP1 never draws to it again. Sprites will appear to move behind the cell. This can also be used to protect areas of the screen not drawn by SP1.

- Characters cells can be mapped to any character cell on the display. SP1 lets you define a rectangular array of character cells that it manages. You can then rearrange that logical rectangular array so that the cells are drawn on screen in any rearranged format. This could be a memory-saving technique. Eg, you only need a game area of 24 chars wide by 20 chars tall plus a few chars for score, level etc. Specify to the library that its display area will be 24 chars wide by 21 chars tall in the customize.asm file. In the program, move the 24x20 game area to the correct position on screen and then map characters in the final row to your score and level display. The rest of the screen, which SP1 will not touch, can be drawn by some other code or utility (such as uncompressed screen$).

- Use of individual 8x8 pixel struct_sp1_cs sprite characters that are not attached to a sprite. Since these are legitimate sprite characters, they can possess any sprite draw function (mask, or, etc) and can lie in any sprite plane. Intended for foreground graphics allowing sprites to move in front of or behind them. A slower method than removing sprite chars from the engine, but these characters can be placed on an intermediate plane. Think fog-of-war tiles covering what is underneath, clouds or mist that obscure what is underneath, moving clouds as in Combat on Atari 2600.

- Customized draw functions for sprites or sprite characters. Maybe you want to alter background colour in a special way, or draw graphics in a different way than the standard mask, or, etc. Think draw functions that draw different graphics based on game state, mirrors and reflections in water (by controlling the order that squares are drawn you have access to a previously drawn square's final graphics).

Since you are already familiar with splib2, jumping into SP1 shouldn't be too much trouble since you can use it as an improved splib2. A lot more of the underlying mechanics of SP1 are exposed in order to make it a more powerful library so an understanding of how things work as described at the beginning of that giant post in WOS will make it much easier to understand and use the advanced features listed (and not listed) above!

I hope I didn't bore you too much with all the above but since there is no complete documentation yet, I thought it would be worthwhile to list some things to keep in mind while learning the more advanced aspects of the library.

I was asked to post a z88dk snapshot at WOS so I'll reproduce the link here for those who don't feel like going the cvs route and would like to give it a try:

http://www.mediafire.com/?5o22ztdxwpw

This is a win32 install that must be placed in c:\ . The z88dk tree will unzip into c:\z88dk. (Don't forget to backup any projects you may have there already!)

I've left a slightly changed spritepack.h and splib2.lib in there which should still work for existing projects.

Thanks and keep up the good work. Your library has injected the scene with sheer, new life.

Cheers and thank you too. The day after you released Phantomas Infinity my web traffic went up 10 times for several months. The traffic has now settled to about 2-3x what it used to be so there has been sustained interest as a result of your games. I used to be able to tell when you were releasing a new game by a spike in interest in the site in the week prior to release but I can't do that anymore as there are now several people seriously using it.

Here's a little something to think about for the future :
http://isa.uniovi.es/~chema/white+noise/intro.htm

[na_th_an]

The underlying gist of how the engine works as described in that post is still correct. And the features it describes are still in the current version of SP1. All the programs will still compile and run if the recent changes are taken into account (get rid of the tables you used to have to declare at the top of the file, change the calls to the sprite create functions, move the stack pointer lower in memory; spotting the differences from the sample program in the last post should make it clear) with the exception of the one using a screen$ as background. The current SP1 uses 16-bit tile codes, which can be a character 0-255 as used in splib2 or a memory address where a UDG is stored. So setting up a background screen involves writing 16-bit tile codes that point into a screen for each character square.

Nice. I remember that until I understood the philosophy of splib2 I could not use the library efficiently, so it's clear that my first step on learning SP1 will be understanding how the library works. I will start my reading as soon as possible, in "slow" moments at work.

The Screen$ as background thingy is an awesome feature that can come handy in games in the fashion of Pang and stuff. It can add really nice aesthetics. I understand how it is implemented and I think it's a pretty clever way of doing it!

[...]a tutorial would be great. If you spend some time understanding how the underlying engine works (a couple of posts near the beginning of that giant thread), the test programs will make a lot of sense and understanding the new features will be a lot easier.

That's what I'll do. I'll be taking notes about what I read and understand. Turning that into a tutorial isn't difficult. I love writing Developing a game while I learn is also a good idea which connects with the next quote...

I think the first step is just to use SP1 as an improved splib2. Everything done in splib2 can be done in SP1 and you can even use the same API calls with changes only to the parameters.

That's what I'll do. I have Phantomas Saga 2: Salem completely planned and I need some of the new features of SP1 to make it look just like I want it to look. As soon as I understand how sprites work completely I think I'll be able to start it. I'll be using RAM pages as well, mainly to store compressed title screens and the map file, so I can switch pages, grab what I need, and switch pages again so SP1's structures are again present at the end of RAM. I don't need 16K of map data for this game, but the switching method will come handy with a future project we have which will feature a massive map, so I will test-drive it with Salem.

Let me comment on the improvements. They look fantastic

- SP1 is slightly faster.

- Code generated will be smaller. The data space required by SP1 is actually larger but I think in large projects the overall size will still be smaller.

I've seen the 7Kb demo you posted. The minimum footprint of splib2 was around 9Kb, so the improvement is quite visible. Plus, all those sprites move so fast. Cake

- You have complete control over the placement of SP1's data structures in memory, unlike splib2 which just attaches it all to your binary.

Awesome, specially when we are talking about page switching It was quite possible with splib2 (Utopian did an awesome work with page switching in Cannon Bubble), but it will be easier with SP1.

- Several annoying things you've had to deal with in splib2 have been removed in SP1 (this is stuff that came up from discussions with you and from looking at your source code, so thanks!): a new sp1_MoveSprPix() function was added to move to pixel coordinates (you used to do all the % and / stuff which made the compiled code ugly), an absolute frame address can now be specified in the move functions (splib2 requires distance from last frame address which complicated matters), new members xthresh and ythresh in the struct_sp1_ss specify the minimum pixel shift required before the last column / last row of the sprite are drawn (you were using a clipping rectangle to stop colours from drawing into a neighbouring char cell caused by the sprite's blank column drawing even when it didn't need to; now the last column is not drawn when not needed).

That's simply amazing. I mean, it will come über-handy. Once you got the grip of the old method it wasn't very difficult to handle, but now it's absolutely intuitive and, as far as I can understand, much more flexible. The xthresh/ythresh stuff comes quite handy - the clipping rectangles around enemies worked fine with linear paths, but once you needed a more bumpy sprite it just didn't work.

And then I think you could start experimenting with some of the new features; I'll list some of them here and what their intended uses are:

- Sprites have attribute masks and attributes, intended to help with colour clash. SevenuP supports all of SP1's graphics and attribute formats.

Great. That way I can play with backgrounds more. Games will look better, that's for granted.

- Dedicated functions sp1_GetSprClrAddr(), sp1_PutSprClr(), sp1_GetSprClr() for quickly colouring sprites. Faster than the old way (and still valid way) involving sp1_IterateSprChar(). Intended to be used inside the game loop.

This is pretty cool, 'cause the sp_IterateSprChar() method was great for off-game loop colourings. Sprites that change color within the game loop - yay

- Quick animation of background tiles by changing tile graphics associated with a particular character code with sp1_TileArray() and then invalidating a list of affected char cells by iterating over them using sp1_IterateUpdateArr() or sp1_IterateUpdateRect(). Think flickering candles, twinkling stars, waving grass, etc.

At last! This thing was something I was quite expecting. MSX coders could do it quite easily as they have tile oriented graphic modes. In splib2 it would have been slowish and costy to manage. I'm glad this feature is now added to the library.

- Removal of individual character squares with sp1_RemoveUpdateStruct(). Draw the cell first with SP1, then remove it so that SP1 never draws to it again. Sprites will appear to move behind the cell. This can also be used to protect areas of the screen not drawn by SP1.

This has been taken in acount in the design of Saga 2: Salem I've drawn some pretty "foreground tiles".

- Characters cells can be mapped to any character cell on the display[...]

Great. Nice way to save heaps of bytes

- Use of individual 8x8 pixel struct_sp1_cs sprite characters that are not attached to a sprite. [...]

This is pretty nice as well. I can't wait to place a nice foreground fence in Salem

- Customized draw functions for sprites or sprite characters. Maybe you want to alter background colour in a special way, or draw graphics in a different way than the standard mask, or, etc. Think draw functions that draw different graphics based on game state, mirrors and reflections in water (by controlling the order that squares are drawn you have access to a previously drawn square's final graphics).

this is simply great. Now the library is fully customizable. Man, congratulations. You've created such a clever, nice, incredibly useful piece of software! Now, with true reasons, all the sceners will hate and envy the Speccy scene!!!

Since you are already familiar with splib2, jumping into SP1 shouldn't be too much trouble since you can use it as an improved splib2. A lot more of the underlying mechanics of SP1 are exposed in order to make it a more powerful library so an understanding of how things work as described at the beginning of that giant post in WOS will make it much easier to understand and use the advanced features listed (and not listed) above!

Nice to know. Now I'm half as scared as I was before. And that helps

I was asked to post a z88dk snapshot at WOS so I'll reproduce the link here for those who don't feel like going the cvs route and would like to give it a try:

http://www.mediafire.com/?5o22ztdxwpw

THANKS. I can't make the cvs client work from where I work (ports closed and stuff like that). So thanks for the snapshot. Installing RIGHT NOW.

Cheers and thank you too. The day after you released Phantomas Infinity my web traffic went up 10 times for several months. The traffic has now settled to about 2-3x what it used to be so there has been sustained interest as a result of your games. I used to be able to tell when you were releasing a new game by a spike in interest in the site in the week prior to release but I can't do that anymore as there are now several people seriously using it.

That's great. I'm so glad The thing is, I think there's a lot of "stubbornness" in the scene about which language you code in. It looks like that people don't consider "really usable" anything besides pure assembly. I think that it's been quite demonstrated that C + your library is an awesome combination for creating great games in half the time and with half the hassle than using pure assembly. Once people leave the general "stubbornness" I'm pretty sure that more people will be using this. C is quite easy to understand and provides easy portability among systems, so ... It's just a matter of time. Inside CEZGS there are now four coders besides me who are working using z88dk and your library

Here's a little something to think about for the future :
http://isa.uniovi.es/~chema/white+noise/intro.htm

That looks incredibly sexy - but I'm still interested in that 64x48 multicolour library you talked about a while ago

Cheers and keep up the good work!

[Karnevi]

Hi!

With my poor english, I only want to say you (as CEZ GS webmaster and "producer") that our work won't be possible without your great SPlib.

I hope you enjoy not only Infinity, but also Cannon Bubble and other games we'll release very soon.

[Benway]

My english is really poor, but I'll try write some words to thank Alvin Albrecht his good work making this superb library.

I'm finishing my first game using it (BeTiled!, a BeJewelled clone, as you can see here), and it's a dream come true to me to make Speccy games in C, and it would'nt be possible without z88dk and SPLIB.

I've downloaded the CVS snapshot that you posted, and I'll start to "play" with the new SP1

Thanks again, mr. Albrecht

Corregidme lo que haya metido la gamba, por favor

[Anjuel]

Hi!

i'm sure that we'll try your new version of splib, and i want to give thanks to you for make our job easiest.

thanks a lot of, Alvin!

[Alcoholics Anonymous]

I hope you enjoy not only Infinity, but also Cannon Bubble and other games we'll release very soon.

Indeed I do -- I follow all the games that CEZ comes up with. CEZ is an important part of the spectrum scene

Thanks to all for the nice words. I do follow your projects, including the ones under development, and look forward to playing them all!

[Alcoholics Anonymous]

- Code generated will be smaller. The data space required by SP1 is actually larger but I think in large projects the overall size will still be smaller.

I've seen the 7Kb demo you posted. The minimum footprint of splib2 was around 9Kb, so the improvement is quite visible. Plus, all those sprites move so fast. Cake

That's still a bit misleading though, as the data area used by splib2 is compiled into that 9k, but the data used by the sp1 demo is not. SP1 programs will be much, much smaller but you have to remember to include that large data area at the top of memory in comparisons.

Awesome, specially when we are talking about page switching It was quite possible with splib2 (Utopian did an awesome work with page switching in Cannon Bubble), but it will be easier with SP1.

What utopian did would be called "the hard way" . I'm impressed he managed to do it as I thought it would take some intimate knowledge of how splib2 works. But maybe he's an expert now and does have that knowledge.

(sprite graphics animation)
Once you got the grip of the old method it wasn't very difficult to handle, but now it's absolutely intuitive and, as far as I can understand, much more flexible.

It simplifies the code for sure. You can still do it the old way, and I've found the old way is actually preferable in some situations. The game I'm writing now, eg, uses a single function to animate walking for all sprites and this uses the "delta" technique in splib2.

At last! This thing was something I was quite expecting. MSX coders could do it quite easily as they have tile oriented graphic modes. In splib2 it would have been slowish and costy to manage. I'm glad this feature is now added to the library.

The MSXers still have the advantage of having the hardware to do it though, whereas SP1 still has to draw the tiles. The MSX1 can do the types of games SP1 was designed for quite well (the MSX1 hw does place limits that a sw engine like SP1 doesn't have but then the hw is very quick in comparison). But when engines for scrollers start to appear, the Spectrum will show some advantages it has in speed

- Use of individual 8x8 pixel struct_sp1_cs sprite characters that are not attached to a sprite. [...]

This is pretty nice as well. I can't wait to place a nice foreground fence in Salem

Unfortunately it's a bit of a memory pig -- each struct_sp1_cs is 24 bytes and you need one for each character square. It all adds up very quickly, but if you plan for 128k at the beginning it should work out quite well.

- Customized draw functions for sprites or sprite characters.

this is simply great. Now the library is fully customizable. Man, congratulations. You've created such a clever, nice, incredibly useful piece of software! Now, with true reasons, all the sceners will hate and envy the Speccy scene!!!

I hope people might find it useful. SP1 is almost as far as I can take the algorithm. There may be a thing or two added that finds uses on other platforms, but it's pretty much time to start working on the next engine.

THANKS. I can't make the cvs client work from where I work (ports closed and stuff like that). So thanks for the snapshot. Installing RIGHT NOW.

If anyone tries to compile the sample program above, let me know if you have any problems. One person has been getting segfault and we're not sure why.

Once people leave the general "stubbornness" I'm pretty sure that more people will be using this. C is quite easy to understand and provides easy portability among systems, so ...

Yep, that's what I think too. It's starting to gaining acceptance, thanks mainly to CEZ, and I think will become accepted as we introduce new engines that can do what no one else is currently doing in the Spectrum scene

Here's a little something to think about for the future :
http://isa.uniovi.es/~chema/white+noise/intro.htm

That looks incredibly sexy - but I'm still interested in that 64x48 multicolour library you talked about a while ago

It'll come... but the isometric one will be first mainly because I didn't have to write it It's coming from the Oric scene where a fellow wrote a C API for his 3d isometric engine. I'm going to port it to the z80 and stick it in z88dk. This brings up another interesting possibility -- cross cpu development between the 6502 and z80.

The 64x48 clash-free colour one I am still interested in bringing out soonish. Since drawing to the display has to be carefully timed with the raster to support such a mode, the program will have to put together sprite and draw code fragments like lego that will be run during the screen refresh. Each of those fragments take a fixed amount of time which is what makes it possible to run them while the raster traces the screen. It'll be a different style of programming.

The main trouble is there isn't enough time in the day to do it all -- I've got two games on my plate, porting SP1, the new engines, and improving z88dk's libraries all on the go. Incidentally, if anyone cares to lend a hand let me know SP1 is about 100 lines away from a port to the MSX1 (with spectrum colour resolution, not the still-coming 32x192 colour resolution). A CPC port will take more effort but if someone from that scene would like to help make decisions about how it should work (and perhaps write some code to support it), let me know. This would speed things along.

[utopian]

Just seen the thread . What I've seen from the SP1 looks cool, so it's just a matter of being brave and making the switch (easier said than done ). Personally, I think I'll try to do some work on a scrolling engine, but if I fail and decide to make another non-scrolling game, I'll give it a try.

BTW, we are doing some work on a kind of "splib2 lite" library to ease the porting of our games to CPC and MSX. It doesn't have all the bells and whistles of splib2, but at least it is enough for us. If you would like to reuse some of the code for the SP1 ports... just let us know.

[Alcoholics Anonymous]

I think I'll try to do some work on a scrolling engine, but if I fail and decide to make another non-scrolling game, I'll give it a try.

If you ever get it into a decent state and feel like sharing, let us know. We are always looking for new engines

BTW, we are doing some work on a kind of "splib2 lite" library to ease the porting of our games to CPC and MSX. It doesn't have all the bells and whistles of splib2, but at least it is enough for us. If you would like to reuse some of the code for the SP1 ports... just let us know.

I spent some time looking at the CPC again after posting and I think I've found a satisfactory path for porting the library in mode 1. I'll stick with 8x8 pixels as the minimum display unit, which means sprites will have to be multiples of 8x8 pixles in size. However, I'll introduce a whole bunch of different sprite draw functions to fit special cases where the sprites are multiples of 4 pixels wide since on the CPC each display byte is 4 pixels wide and forcing sprites to draw 8 pixels is a waste of time. I've been fearing this route because of the shear number of different sprite draw functions this would introduce but I think I'll just suck it up and do it. The alternative was to go for 4x8 pixel units but this would double the size of the data area in comparison to the Spectrum, slow things down further (twice as many display units in a sprite of the same size as the spectrum = half as fast move functions and the CPC is already slower than the spectrum because of the increased display resolution), and you wouldn't be able to print text as easily as on the spectrum (who can make sense of 4 pixel wide chars?).

I am curious to hear how you are doing the MSX1 version. Is it a spectrum-like colour resolution or are you attempting a true mode 2 colour resolution (32x192)? I haven't decided yet how to best deal with the higher colour resolution and wouldn't mind hearing some ideas if people at CEZ have thought about it already.

[na_th_an]

I believe they are creating functions to define the tile info (in full 8x1 attributes) and then mapping the sprite functions to HW processing. So sprites will be handled by hardware.

I mean, this is not a proper "port", but a replacement library we can easily adapt our code to. AFAIK it will include functions to poke tiles in the tile memory (using a tile oriented graphic mode rather than a bitmap based one), functions to define sprites and functions to move them around, as well as keyboard scanning.

[utopian]

I think I'll try to do some work on a scrolling engine, but if I fail and decide to make another non-scrolling game, I'll give it a try.

If you ever get it into a decent state and feel like sharing, let us know. We are always looking for new engines

Well... Currently it's just a quick&dirty design on paper. There's a loooong way before having something visible. But yes, if I manage to make a decently usable library, I'll share it for sure.

I am curious to hear how you are doing the MSX1 version. Is it a spectrum-like colour resolution or are you attempting a true mode 2 colour resolution (32x192)? I haven't decided yet how to best deal with the higher colour resolution and wouldn't mind hearing some ideas if people at CEZ have thought about it already.

As na_th_an said, I am using full 8x1 coloured tiles and HW sprites. Anything else would be a sin for MSXers . I am also creating a replacement crt0.s for MSX machines, to allow creating ROM cartridges. I didn't know that z88dk was such an ugly beast to do ROMable code

[Alcoholics Anonymous]

As na_th_an said, I am using full 8x1 coloured tiles and HW sprites. Anything else would be a sin for MSXers .

There is something to be said for the gain in speed from ignoring the higher colour resolution but with hw sprites that's not so much a problem anymore. But then you've got to worry about the 5 sprites per scan line limit too. When you get it up and running I wouldn't mind having a peek at the source, if you're willing, to pick off some ideas Are you looking at CPC+ sprites as well? It's in the back of my mind to write a more-or-less generic hw sprite API that would be able to combine individual sprites into a single large moveable object and then somehow deal with the limits on number of sprites per scan line automatically.

I am also creating a replacement crt0.s for MSX machines, to allow creating ROM cartridges. I didn't know that z88dk was such an ugly beast to do ROMable code

Yes, indeed z80asm is a pretty good assembler (with its quirks) but the one essential thing it is missing is multiple code and data segments. We're moving to the next version of z80asm (called mpm) at some point and it is supposed to introduce multiple segments but that feature is not in it yet and there is no real reason to change until it is in there.

The C compiler does separate static/global C variables from C code and can place static/global C variables in RAM separate from the compiled ROM code using a special DEFVARS directive in the crt. I've never done it so can't say for sure offhand how to do it.

However for asm code, I've found the best way is just to have a file listing addresses of asm variables with DEFC declarations as I did with customize.asm in SP1. That way you can change the memory map by editing this file at the same time that you've separated out RAM variables from ROM code.

Anyway, be sure to use the CVS version of z88dk for any stuff you release as the next release of z88dk will be coming along in the next few months and may obsolete some of the ways the older version does things.
An MSX cart crt0 is a great idea; in fact I was planning to do the same for IF2 carts and timex carts. Let us know about it when it's in good shape -- if you're willing to share I'd like to make it part of z88dk.