CPCWiki forum

Hi all.

For the last 2 months I've been taking a little break from Chunky Pixel Collision.
I felt that I needed to step away from it a little bit as I was feeling burnout approaching!

Anyway, to relax(!!!) I had a go at creating something I've wanted to do for a long time:
A full-screen, character-based, tile engine with parallax scrolling.

It has 4 layers of parallax: a static "wallpaper" layer for things that are really far away, a background layer, the playfield layer, and a foreground layer. The background layer moves at half the speed of the playfield, while the foreground layer moves at twice the speed of the playfield.

I've used some simple graphics based on the arcade version of Pacland.
Makes me wonder what the CPC version of Pacland could have been like (even though it is still very playable).

When the program loads, it lets you decide how big to make the 4 borders around the screen.
Leaving them at default will make the program run at full-screen.
For a spectrum sized screen, use top=0, bottom=1, left=4, right=4.
Don't use "impossible" borders, as the program will crash (ie. make sure that (top+bottom) is less than 25, and (left+right) is less than 40).

Use the arrow keys to move the camera in any direction.
The parallax works vertically as well, though I have built in the ability to lock any axis (this facility isn't demonstrated in the attached dsk file).

I wrote this using the wonderful ccz80 compiler, with assembler for the speed-critical bits, like processing the sprite data, and printing the tiles to the screen.

I've used adaptive screen refresh, only printing tiles that change from frame to frame.
Objects can be placed anywhere in a play area of 65536 x 65536 tiles, and when the camera reaches the edges of the play area, it wraps around correctly (I hope!).
The number of objects is limited by RAM (I'm only using the base 64K), though the number of tiles is (at the moment) limited to 255. The tile limit problem is already solved in my brain, but I don't know if I'll end up putting it into the program...

I don't know if I'll do any more work on this - it was just something I needed to get out of my system.
I hope you all enjoy it (what little there is of it, anyway)!

[EDIT #1] tiles2.dsk contains the ability to toggle the layers on/off.
[EDIT #2] I've attached the current version of the source code, in case anyone is interested. It's written in ccz80.

That's actually really well done, the speed is way better than expected  :)

Very nice speed you have there - an excellent tech demo. You may well find that you put it to one side for a bit then decide at some future point that you fancy revisiting it again.


Nice one!

Thanks guys.

Indeed, things like this usually stay in the back of my mind and occasionally pop up and want to be revisited!

Maybe one day I'll put collision detection in there, so that a character can walk in the playfield layer, jumping over and landing on platforms. Or maybe a scrolling shooter would be worth persuing.

Actually a scrolling shooter with background elements containing lots of repetition (so fewer character cells change from frame to frame) would run really quickly with this engine.

QuoteMakes me wonder what the CPC version of Pacland could have been like

you mean with a scrolling ?




BTW I got a look at your thing, (winape only) and it looks nice...

Of course as the tiles are unmasked there are a lot of attribute artefacts (I guess the tileset you used wasn't well set at characters sizes, as seen for the roofs), it would need a proper redesign / especially designed tiles in order to accomodate those square corners artefacts.


Or to get those tiles masked, which can then be really reicky as there are quite a few layers here.


or something bit like the way R-Type 128k managed to get along with those, using a black colour for the background per exemple, or "cycled/animated" tiles for the medium layer in order to give some paralax effect, I guess.




Also as there is no masked sprites yet...
adding such sprites (some of them automated/ with an AI) could also clearly reduce the fluidity, smoothness or speed.




But it is a nice begining I guess.
You told us it used only 64K of RAM yet manages to go "overscan" ?




Haven't seen thez tiles number/mass limitation, but it looks like such engine could be used to get a fine shadow of the beast "interior stages" effect, with a nice background fixed picture, simple foreground (designed so the squares attributes may not hurt too much) and just masked sprites over those.


would be nice to see how good it would work on a PLUS with it's ASIC unlocked too...
I guess it does not use the smooth Horizontal Hard-scrolling from PLUS, but still : extra palette and Hardsprites and shittons of rasters are always good to play with (and also 128K RAM or cartridge ROM, DMA sound channels...).




If I recall well, AMC (astro Marine Corps) used some engine not unlike this one to have a sweet parralax effort despite being character (and unmasked) based.


Such engine could really do a great Shoot'hem up engine, for something like "Blood Money" (Amiga/Atari ST) game.




could you explain the borders settings please ? how does it work ? what are the values range ?
Can it go fullscreen/Borderless ?
(the one using 32K in RAM, well 24K actually...)

Quotethough the number of tiles is (at the moment) limited to 255. The tile limit problem is already solved in my brain, but I don't know if I'll end up putting it into the program...

so the whole "beast" can use only 255 tiles but can use them for any layer ?


what are the limitations concerning number tiles used per layer ?


Also would it be possible to see how it works with like one less layer ?

 :D

Yes indeed, the graphics are not ideal for a character-based engine.
The graphics were chosen simply as an example. I just wanted to demonstrate the speed and I needed something to do that with.

I've actually solved the issue of corner artefacts. The solution is in my brain and likely won't get implemented, but the idea is to mask edges of objects, and leave the insides unmasked. This would have less of an impact on speed than just masking everything.
And masked sprites would also have an effect on the speed.

But the point of this engine was to have everything character-based (and unmasked) for speed. I thought that the corner artefacts would be a worthwhile compromise, as long as the tiles are designed with that limitation in mind.

By "overscan", do you mean "full-screen"?
When I say full-screen, I mean simply that the entire 16K screen can be used, instead of shrinking the screen to be the same size as the spectrum's.

As you say, AMC does have a similar engine, but of course with a much smaller playing area. Maybe I should prepare a demo using graphics from that game... depends how much spare time I have.
I believe both Turrican games use an unmasked character-based engine as well, but I don't know if they have parallax scrolling (though I think Turrican 2's 3rd level did).

The borders settings are simply to allow the playing area to be shrunken for extra speed.
I don't change the default borders at all (in fact I don't use any CRTC/hardware tricks - it's all pure z80 code).
You can have a top border of 24 and a bottom border of 0, or vice versa, and it will work. You won't be able to see very much, but it will work, and it will be very fast. The point is that there must be at least 1 row visible, and 1 column visible. There is no error checking on the border settings, and having no visible rows or columns will likely cause the program to crash.

The 255 tiles limitation is there simply because I haven't bothered (yet) to put the tiles into banks (I'm not talking about the CPC's memory banks, rather I'm talking about the concept of grouping the tiles into "sets" of 255).

The tiles are referenced in an 8-bit offset table. I tried a 16-bit table, and it was much slower, so I kept it 8-bit.
Putting the tiles into banks will remove the 255 tile limit.

Any tile can be in any of the 4 layers - there is no limitation regarding that.
If I get some time, I'll prepare a version where you can switch layers on/off to see how it affects the program's speed.

By the way - I always enjoy your analytical posts. They're always interesting, even though I don't share the same enthusiasm for the PLUS range!  ;)

QuoteThe borders settings are simply to allow the playing area to be shrunken for extra speed.

Ok, then you don't say full screen but "normal CPC screen"...
the speccy sized screen is "speccy sized" screen or reduced standard display, you also have standard 16K settings with different shapes, like a "256x256" screen which is "vertical full screen", as used in Arkanoid.
(or donkey kong, Titan... Ghouls'N'Ghost too...


And while those reduced screens enable faster things (because far less tiles to refresh/move) it can also enable to re-use the unused screen RAM on the 216K screen VRAM bank (the border zone), I guess (not sure, this may also be used to ease some scrollings ?


the "fullscreen" actually often means "borderless" screen that is so often used in Demos.
the 32K (actually24K) doubled screen the CPC is proud to be able to do (compared to the rest of the 8 bit world).


But there are not unique way to talk about it, each one have his own language concernign this, hence the often called "overscan mode" (which it is not really).

QuoteI've actually solved the issue of corner artefacts. The solution is in my brain and likely won't get implemented, but the idea is to mask edges of objects, and leave the insides unmasked. This would have less of an impact on speed than just masking everything.And masked sprites would also have an effect on the speed.

Well, if you limite the masked tiles to only a few of them, it can be ok, but as there are many layers this can really be a lot heavier fastly.


Same with sprites, you can do them in "character grid move" so they may not move that smoothly, and get them a mix of masked and unmasked tiles...
all of this can complicate a lot of course.


While it is possible to do sprites OR scrollings on CPC, having both really gets heavier fastly for poor old CPU.


A good way is to benefit from ROM or Extra RAM so you can multiply the sets to get them prebuffered and/or preshifted/moved.


And yep, having those tiles in "8bit" means 256 (0-255) tiles...
Perhaps you could get each layer to have its own  tileset.


but again, this means so many more stuff to manage and would reduce a lot of CPU I guess.




As I told you, you engine could be great for shooters, "railed" ones.


Something like Blood Money.


Atari ST - Bloodmoney (http://www.youtube.com/watch?v=Os4eLoEtF9A#)


this with some paralax effect.
As you can see the tiles are designed in quite square character style, so it could be great with your engine, perhaps i should look if it is possible to find those ripped somewhere and to convert them into CPC mode.

The good point with this is that you can cheat a bit because the scrolling is "pre calculated"... automatic/railroaded..
less need to get into some gravity or too complex collisions, and the monster's sprites often have pre-calculated/set  regular patterns.

But again, just adding masks, sprites and colision may get your engine really sluggish, sadly.


On the  other hand, as you already have a lot of layers, you can simply replace one of those layer by the sprites layer too.
And/or some PLUS HardSprites too...  ;)


Another good use would be a Shadow of the Beast clone.


Amiga - Shadow of the Beast - Part 1 of 3 (http://www.youtube.com/watch?v=KHU2guYH7Og#)


the dungeons parts need only 2 layers (background and forground) and sprites over those (so 3 layers)
the foreground tiles can need only a minimum of masked tiles too(if any) depending on the style of graphic you get.


Psygnosis was prone to put a lot of finely artistically masked stuffs... but on a CPC this may be simpler.


And I guess the background wouldn't be as colourfull : the more black you put, the easier it is to reduce the unmasked effect.

A good exemple of simpler background with a lot of black... Xenon2 megablast...
Amiga Longplay [127] Xenon 2 - Megablast (http://www.youtube.com/watch?v=DCAUTrgso8k#)


Here the background layer would use like only 2-3 colours perhaps, so you can use colours not used by the rest of tiles, a way like i did for Rick Dangerous 128+.


of course a lot of sprites but again, no need to have as many layers... and the foreground can be done in a way so it use more squares tiles and the sprites wouldn't be over it but between the foreground and background, hence only the sprites could need to be actually masked.


But hey, those "biological/living biomass biomess from hell" designs are more than likely to have "laced" masked designs than more industrial stuffs.


And also, having some bigger levels patterns, sprites and masks, and more importantly : collisions...
This could really screw up your engine into a "sluggish slnailfest slowpoke".. got to see perhaps.


Oh, I also remember this cool game on Atari Lynx : GATES OF ZENDOCON


GATES OF ZENDOCON - Atari Lynx (1989) (http://www.youtube.com/watch?v=MFq2EhcPMKk#ws)


Some levels have such Paralax multilayered effect that is so kool.

QuoteI wrote this using the wonderful ccz80 compiler, with assembler for the speed-critical bits, like processing the sprite data, and printing the tiles to the screen.

So I guess this engine was especially CPC designed...
good point as most games we had were speccy designed... I guess this could give some margin to have something fast after all.


Also perhaps the modern compilers are better and more powerfull than the ones that existed in the 80's...

QuoteBy the way - I always enjoy your analytical posts. They're always interesting, even though I don't share the same enthusiasm for the PLUS range!

And also for the Atari STE... I like the fact those were never really exploited, i see this as some sort of revenge, and the palette itself is so much awesome to use.
Thx anyway, you're welcomed.

What an outstanding post!
Brilliant! Lots to think about, and some great ideas.

Yeah, just to clarify, by "full-screen" I mean the full area inside the default border.
If I was to use the border area as well, I would run out of memory, and the program would get a low slower as well.
Considering that even a game like Savage only uses around half of the area inside the border for the actual play area, I'm happy with what I've done. :)

Indeed, having to mask object edges through different layers is tricky.
My solution is like this (although of course it isn't coded, and in reality would be more complicated):

- Check nearest layer character cell.
    - if the cell hasn't changed from the previous frame, and it isn't flagged as requiring a mask, ignore the character cell.
    - if it hasn't changed but is flagged as requiring a mask, check the character cell in the layer behind it.
    - if the nearest layer character cell has changed however, it needs to be printed.
        - if it also needs masking, will need to check the cells behind it.

The same logic will be needed for relevant cells in the playfield layer, and then cells in the background layer.
The "wallpaper" layer won't need any masking at all, as of course that will always be at the back.

As you can see, this will have quite a large impact on the engine's performance. :(

Regarding tiles, I might yet implement tiles "sets", so that the number of tiles is limited only by available RAM.
I've been thinking about it, and I believe I have a good solution.

Blood Money - I remember the first time I saw this game on a friend's Amiga, all those years ago.
It was absolutely beautiful for its time. So damn difficult though!
Yes, I believe a game like that could be made in my engine quite successfully, though all movement would be character-based.
The background layer could actually be static, as that would mean that it wouldn't need to be refreshed from frame-to-frame (unless something passes over it).

Shadow of the Beast - this was actually my initial inspiration for the multiple layers and parallax scrolling.
I think it could be done very well using my engine, as long as the background layer was static.

An interesting thing to note about Shadow of the Beast on the Amiga is the lack of masking on several sprites in the outdoor areas! There are a few places where a large group of sprites (spheres, or eyes, I'm not quite sure) will arc over your character, and if you look closely, they are unmasked and have square artefacts around them.
No doubt this helped keep the speed up, considering the amazing parallax scrolling of those sections.

Xenon 2 - once again this would work very well with a static background layer, with just the foreground layer scrolling.
The original version didn't even have very smooth sprite movement, so that would transfer quite well.

Bigger level patterns in my engine won't make much difference to the speed, as all the objects in the level are looped through very quickly. Anything that is too far away from the "visible" area of the level is ignored. That took a long time to get right!

Thanks for the great posts man, I'm really enjoying this thread.

Hi everyone.

I've attached a new version (tiles2.dsk) to the first post in this thread.
Based on a suggestion from MacDeath, I've implemented toggling for the 4 layers.
Each of the 4 layers can now be switched on/off by pressing keys 1 to 4.

The speed difference with the playfield switched off (layer 3) is predictably huge, as that is the layer with the most detail in it.
:)

Concerning maskes, have you considered using a 1bpp (bit per pixel) limited set of maskes, so you could have simple masked character shapes, like half a char, of diagonal edged one, and so on...


such masks could then be applied to any tiles, as needed.


The problem with those character tiles is that you mostly just have a few "unmasked corners" that spoil the pictures here and there.
So just having a few "standard" masks could be enough.

Like round corners or diagonal corners only so you may have some losange shaped masked stuffs, per exemple.

QuoteAn interesting thing to note about Shadow of the Beast on the Amiga is the lack of masking on several sprites in the outdoor areas! There are a few places where a large group of sprites (spheres, or eyes, I'm not quite sure) will arc over your character, and if you look closely, they are unmasked and have square artefacts around them.No doubt this helped keep the speed up, considering the amazing parallax scrolling of those sections.

That's because of the hardsprites limitations on amiga.
You are limited to a not so huge number of sprites on the same scanline so sometimes the player's sprite have priority over others...


They are quite multiplexed vertically though.


Also you can see those sprites are quite limited in colours.


There the amstrad PLUS can add so much thx to its few masked Hardsprites.
if you look at R-Type on MSX.
It is character based as on spectrum (yet less sever attribute limitations).
But a few sprites are not character based but Hardsprite based... they move smoothly (the R9... or the Force modules and so on) yet the "bullets" are still character based, hence a few unmasked character  corners when you use the tri-laser or the weapon with circles in the few levels with a background.



When we were arguing about the last R-Type CPC6128 version at the "Gamopat forum" (a french retro computer/retrogaming forum/site), the C64 and MSX fanboyz told us (us the Amstrad bastards) that the Amstrad was still shit because it wasn't as "smooth" as the MSX version...(and the c64 is always best of course)
Seriously WTF ?


Just see there :


http://www.youtube.com/watch?v=HYOIcfMshNI (http://www.youtube.com/watch?v=HYOIcfMshNI#)
Irem's R-TYPE on the MSX - Stage 6 (http://www.youtube.com/watch?v=FeawgxEpcQo#)


ok the MSX version is quite impressive for a MSX1 specs...
but...


=the scrolling is total unsmooth shitfest : movement per complete characters.
=lots of unmasked artefacts when dealing with background and some weapons.


but "hey, the R-9 and the force are in masked Hardsprites so it is smoother and better in all way".
d'oh!
:-X


So there comes the PLUS, to show them how is can be done even betterly.

Hmmm, I hadn't thought of that idea.
I'll have a look into it if I have some time.

I'm just worried that having to mask through the layers will cause a large performance hit.

not sure if actually practical, but I guess no more than 16 mask tiles in 1bpp would actually be needed.


but as you are in mode0...
I suppose you use 4x8 tiles (square mode0 characters) so i'm not even sure it could be possible to have such 4x8 characters in 1bit per pixel...


to use 8x8 characters in Mode0 could also prove a bit trickier as those would no more be square tiles.


Yet to have an extra "mask tile" could be usefull as it wouldn't need to sacrifice a colour.
Not sure what best solution (you are the coder) nor if any sort mask can be that practical after all, CPU wise.


Those multi layered masked tiles could proove heavy in those isometric games per exemple, need to check a lot of layers of masks, but rarely scrollings though...
(see games like Head over heels)






I wanted to know too :


I opened a topic at CPCrulez (french forum/site) becausse I know a lot of french don't speack english and would not come here too often.
http://cpcrulez.fr/forum/viewtopic.php?f=4&t=4911 (http://cpcrulez.fr/forum/viewtopic.php?f=4&t=4911)

Do you plan to do something with your engine ?
Do you want to publish the sources too ?


(just asking)

That's really cool of you - thanks man!
It's really nice knowing that someone is interested in something I have created.

I don't know if I'm going to do anything useful with the engine.
I wrote it as a tech demo, as I just wanted to see if my idea was possible.

The masks issue might be tough to solve...

I'm very happy to share the source code.
It's ccz80 code, which is very C-like, with a fair bit of assembler mixed in.
I've attached the current version to the first post in this thread.

Well, a good use for thise would be to first test it in many stretched way to see what it can handle, and mostly to feed it with more proper tilest so it can do some demo scrolls...


like scrolltexts and so on, Asteroids effects, horizon with clouds and rocks or whatever stuffs...

The unmasked aspect can seriously be worked on right in the creative phase... but this too has limit.

if only a few "mask" patches could be done, they would need to be used jsut a few times here and thaere so the most annoying unmasked angles could get rid of... but if it is not possible, well, lets work with them anyway.

Good point is that you have quite a lot of layers...
So it is still conceivable to remove one I guess, and it would still be quite usable for a game.

As I shown, most 16bit games actually used only 3 layers at best : Background, mediumground and sprites.

Even Shadow of the beast in the "interior" levels use only that.

QuoteI don't know if I'm going to do anything useful with the engine.I wrote it as a tech demo, as I just wanted to see if my idea was possible.

well, it may need some extra tests I guess to see where it can go...
at worse, you shouyld turn it into a "demo maker" utilitary...
someone would just need to provide this code a tileset and a few settings, also a tilemap and then set automatic or not scrolling wanted, tadda... a new demo scroller easily done (or not...).
This could really be a nice tool for some graphicians who can't code shit (like me) to test their tilesets of do scrollers/scrolltextes or whatever.


What happens if you only remove the "fixed" background..?
I will test it tomorow (it is Europe here, I should go to bed now)


But As I already told...
Having to add some sprites, sounds effects or music, perhaps a few maskes, collisions, a score and lives counter/management, various enemies waves patterns, some bosses and a few games mechanics, more tiles, 128K managements and so on.
This may actually turn it into something... different and not as efficient after all. :D


But hey, according to the awesome shooters we had from Australia recently, nothing seems impossible after all.






oh... a Super Mario Like like Game could use this... those bricks are not that round shaped after all.
Itcould be cool with a slight dose of paralax.


Also would be cool to see if it could support Mode1 too.

Indeed a Super Mario Bros game would be great in this engine.
Especially if the background doesn't change too much frame-to-frame.

R-Type on the MSX looks pretty good actually.
The scrolling looks rough because it is a *slow* character-based scroll, but I'm not really bothered by that.
But character-based scrolling certainly looks better with faster scrolls.

For example, Karnov on the CPC and Speccy is character-based, but perfectly fine.
(I think the CPC version used hardware scrolling actually).

Quote from: MacDeath on 02:04, 03 August 12When we were arguing about the last R-Type CPC6128 version at the "Gamopat forum", the C64 and MSX fanboyz told us that the Amstrad was still shit because it wasn't as "smooth" as the MSX version...(and the c64 is always best of course)

You speak like some peoples said that. But only one: The big troll named Youki. He is just hypocrite, and you play his game. Speaking about that only make it's pleasure...

Quote from: MacDeath on 02:04, 03 August 12

ok the MSX version is quite impressive for a MSX1 specs...
but...


=the scrolling is total unsmooth shitfest : movement per complete characters.
=lots of unmasked artefacts when dealing with background and some weapons.


but "hey, the R-9 and the force are in masked Hardsprites so it is smoother and better in all way".

The standard MSX1, can't do pixel scrolling. This was added in later MSX2 I think.
Also, direct access to MSX1 video ram is not so easy I believe, you have to read write through an I/O port.
However, it has char/tile based modes which make more of this easier.

Quote from: MacDeath on 02:04, 03 August 12
When we were arguing about the last R-Type CPC6128 version at the "Gamopat forum" (a french retro computer/retrogaming forum/site), the C64 and MSX fanboyz told us (us the Amstrad bastards) that the Amstrad was still shit because it wasn't as "smooth" as the MSX version...(and the c64 is always best of course)
Seriously WTF ?

Maybe they talk about the smoothness of the play, the movement of the ships and the enemies is smooth and it is at 50Hz?
Making it more fun to move and more response to your actions?
I don't have a problem with this char based scroll, it would not be so bad to use this on cpc sometimes.
It is better than some of the other scroll methods, where the whole screen scrolls on when you get to the sides.
If the scrolling is continuous, or moves with the character, but char based, then that is nice.
but if the whole thing moves in one big chunk each time you enter a new area - I think WHY have scrolling?
It adds nothing here.

I've still only tried this on an emulator, but I was very impressed with its speed. Well done!

Thanks ralferoo.

With all this interest that my program has generated, I'm tempted to keep working on it (though a bit less intensely)!
:)

Quote from: ervin on 02:58, 03 August 12
I'm very happy to share the source code.
It's ccz80 code, which is very C-like, with a fair bit of assembler mixed in.
I've attached the current version to the first post in this thread.

That would be good.  :)


I disassembled some of this program and noticed it was generating "INC SP" which was also something I noticed the recent BASIC compiler was doing when generating Assembly routines out of BASIC programs. Do you know if there is some advantage to this?

Quote from: arnoldemu on 08:57, 03 August 12
I don't have a problem with this char based scroll, it would not be so bad to use this on cpc sometimes.
It is better than some of the other scroll methods, where the whole screen scrolls on when you get to the sides.
If the scrolling is continuous, or moves with the character, but char based, then that is nice.

I agree. I'm a huge fan of the Nemesis/Gradius series on the MSX, and the scroll doesn't bother me at all. I don't even notice it when playing.

Quote from: CP/M User on 12:10, 03 August 12

That would be good.  :)


I disassembled some of this program and noticed it was generating "INC SP" which was also something I noticed the recent BASIC compiler was doing when generating Assembly routines out of BASIC programs. Do you know if there is some advantage to this?

Spoiler: ShowHide

I changed some of them around to "POP AF" which requires less space. Your Pacland Demonstration program still functioned, though I'm unsure my emulator might have been running a bit scrappy at the time I initially ran the program cause it seemed to run faster when I replaced a few of those increasing the SP area with POPing it instead. Unsure.

Interesting... I'm not actually explicitly using INC SP anywhere in my code, but I'm using quite a lot of self-modifying code so I'd imagine that disassembling it could be inaccurate?

Can you give me an example of what you changed? I'm fascinated to know if there is any merit in studying the effects of replacing the INC SP's with POP AF.

Also, I've attached the source code to the first post in this thread.  :)

Interesting !

Char based scrolling games can be good.
Have a look at Duke Nukem 1 (the first version in EGA) on PC.
Good memories of this game !
:)

Quote from: ervin on 12:39, 03 August 12
Interesting... I'm not actually explicitly using INC SP anywhere in my code, but I'm using quite a lot of self-modifying code so I'd imagine that disassembling it could be inaccurate?

In this case it's probably the Compiler that maybe taking some of your C Code and using "INC SP" just to Increase the Stack Pointer, instead of using "POP <reg>". I found this was the case with CPC Basic 3, which is a nice little program for someone looking to understand Assembly better. In my BASIC example though it was "PUSHing" and values onto the Stack Pointer and using "INC SP" to free up the space.
Technically speaking it works, though I'm unsure what the downside of it is apart from using up more memory (which isn't a lot). 

QuoteCan you give me an example of what you changed? I'm fascinated to know if there is any merit in studying the effects of replacing the INC SP's with POP AF.

I could be wrong with that "POP AF" statement  :( From the Binary code in your Disk Image which Begins at &4000 and Executes at &4000, I just began Disassembling the code and for every "PUSH" statement there's 2 "INC SP", I think in your program it was HL which was being pushed. In some places the code was being PUSHed multiple times and I think I counted up to 6 "INC SP" in a row. I didn't change many around, just around the start of the code.
In the Disassembly where it has "INC SP" replace it with "POP HL" (I think) cause it's PUSHing HL (the code shows this in the Disassembly). In some places it had "PUSH HL" twice (I think) and 4 "INC SP" to counteract that, where's "POP HL" only needs to be done twice, in your example I replaced the 2 additional "INC SP" with NOP - &00.

QuoteAlso, I've attached the source code to the first post in this thread.  :)

Sorry I wasn't looking there! :(

Quote

QuoteAlso, I've attached the source code to the first post in this thread.

  Sorry I wasn't looking there!

haha, good old hacker can't wait the release and go hack their way the hard way.

Very nice job ! i love tiles based rendering  ;)
Didn't have time to look more at the source code but i have some questions , how do store and draw your tiles , there are optimisations or it is linear ?

Quote from: ervin on 12:39, 03 August 12
Interesting... I'm not actually explicitly using INC SP anywhere in my code, but I'm using quite a lot of self-modifying code so I'd imagine that disassembling it could be inaccurate?

From what I can work out, it isn't being applied in the tile engine sequence. It's doing a lot of 'PUSH AF'..'INC SP' during the setup stages of the program and where the Border is meant to go, though once it's done all that there are no more 'PUSH AF'..'INC SP'. Though I noticed that large 'PUSH DE' in the Disassembly (along with your source) and perhaps 1 or 2 'PUSH HL'..'POP HL' sequences.

QuoteCan you give me an example of what you changed? I'm fascinated to know if there is any merit in studying the effects of replacing the INC SP's with POP AF.

From the Binary file (Tiles.bin), I replaced 'INC SP' (opcode 33) with 'POP AF' (opcode F1), though to really improve the code it's better to have an Assembly Source cause the only advantage I see in it is your saving a few bytes here and there cause for every "PUSH AF", to return the Stack Pointer back to where it was you need 2 "INC SP", and cause your program is using 3x"PUSH AF" in some places, it needs 6x"INC SP" to counteract that. If "POP AF" is being used, only 3 are required and you save 3 bytes. Cause that little sequence was doing it so many times, I think there's about 20 bytes extra taking up room. Seems silly to go to the hassle.  :D

Quote from: CP/M User on 10:44, 04 August 12
From what I can work out, it isn't being applied in the tile engine sequence. It's doing a lot of 'PUSH AF'..'INC SP' during the setup stages of the program and where the Border is meant to go, though once it's done all that there are no more 'PUSH AF'..'INC SP'. Though I noticed that large 'PUSH DE' in the Disassembly (along with your source) and perhaps 1 or 2 'PUSH HL'..'POP HL' sequences.

From the Binary file (Tiles.bin), I replaced 'INC SP' (opcode 33) with 'POP AF' (opcode F1), though to really improve the code it's better to have an Assembly Source cause the only advantage I see in it is your saving a few bytes here and there cause for every "PUSH AF", to return the Stack Pointer back to where it was you need 2 "INC SP", and cause your program is using 3x"PUSH AF" in some places, it needs 6x"INC SP" to counteract that. If "POP AF" is being used, only 3 are required and you save 3 bytes. Cause that little sequence was doing it so many times, I think there's about 20 bytes extra taking up room. Seems silly to go to the hassle.  :D

Ah yes, I had a look through the asm file produced by ccz80, and the INC SP's are all done during border, locate etc. commands.
It's probably something to do with the way the compiler passes parameters around.

The large PUSH DE sequence is how I clear a 1000-byte buffer each frame. I love that technique - it's really quick.
I first encountered the technique when I was reading about how David Webb (I think that is his name) wrote Starion, and how he cleared the screen before drawing the next screen update. Of course, it's a well known technique, but it was new to me, and when I tried it I was astonished by how quickly it cleared a large area of memory!

Other PUSH/POP pairs are unfortunately unavoidable instances where HL and DE need to be tucked away safely for a brief moment before returning to their former glory in order to correctly continue a loop.

Quote from: fano on 19:48, 03 August 12
Very nice job ! i love tiles based rendering  ;)
Didn't have time to look more at the source code but i have some questions , how do store and draw your tiles , there are optimisations or it is linear ?

Thanks fano.

Before I explain how I draw the tiles, I need to explain what happens each frame.

Their are 2 1000-byte buffers.
One is for the previous frame, and the other is for the current frame.
Each byte represent one character cell, and can contain any 8-bit number (which is why my tile references are currently 8-bit).

Anyway, both buffers are looped through together in each frame, and if they both contain the same value in the same cell, I ignore the cell. If they contain different values, I print a tile to that cell. This is where most of the speed comes from.

Alrighty, on to the data structures...

I have a number of 16-byte tile arrays, labelled a0 to a169.
There is a table called tblTile, which contains 16-bit addresses pointing to these tile arrays.

There are a number of objects (like PACLAND_HOUSE, SUN etc.) which contain 8-bit values. These are offsets that tell the program which element to look at inside tblTile.
For example, PACLAND_HOUSE has this as its first line of tile references:
005,006,007,007,007,007,007,007,007,007,007,007,007,008,009,010,

This means: use the 6th tile referenced in tblTile (0-based, so 005 is the 6th element), then use the 7th tile, then use the 8th tile several times, then use the 9th tile etc.

I also have a number of arrays for which layers objects belong in, what their X and Y positions are, and I also store each object's width, height and some other info.

Each frame calculates which object is within a certain distance of the viewport, and whether or not that object should be ignored for the current frame.
Any object that is not ignored has its position stored in a temporary variable, which is then adjusted in relation to the camera's position, and further adjusted based on which layer it is in.
This bit is quite messy and I actually can't remember how it works! I should have put more comments in!  :-[

Clipping is then worked out, and the required tile offsets are put into the 1000-byte buffer that will be printed to the screen.
The buffer is processed as described above near the start of this post.

Now, I have a problem with the tiles. I can only have 255 tiles at the moment, which is a really bad limitation.
I've thought of having another table containing a "tileBank" value for each cell, but this is a bit messy and would slow things down a bit.

Ideally, I should not have tblTile at all, and have the objects simply storing the 16-bit addresses of the tiles they require.
Unfortunately, all the objects would then take twice as much memory, and so would the 2 1000-byte buffers.
Also, the loop to compare the current and previous buffers would slow down as well.

However, the printing of tiles would actually become faster, as I would be able to remove the tblTile lookup code.
So I need to run a number of tests based on how many tiles need to be printed each frame, and see if removing tblTile would result in a faster engine overall, despite having slower buffer cell comparisons.

I'll report back after I have some more useful info.

Do you have some scripts or application to easily enter any tileset and/or tilemapping into the code ?


Would be nice so guys who can't code but can into pixeling could play and test with this engine.

I have got a very basic program which reads a bitmap and then creates data statements for me, but it's really messy and needs more work (some manual work is required to turn the resulting data into something useful within the ccz80 program). Also, I'm going to try changing the tile references to 16-bit, and this will cause the tile application to need some changes (but it will also simplify it).

When I've got something usable, I'll upload it.

65536 tiles ?

Or perhaps you will use some of those extra bits to differenciate different sort of "tiles", like adding colision or transparency ink/mask or indicatingthe layer to which it would apply ? (just asking)


The multiscroll/paralax is meant to give some sort of deepness so I guess each layer actually would never use some same common tiles.

If there was enough memory, certainly you could have 65536 tiles, but of course RAM will run out long before that number is reached.

It's up to the artist whether or not tiles would ever be shared among the different layers.
Certainly blocks of solid colour could be shared.

Anyway, I've just finished converting the program to use 16-bit for tile references, and I've been able to remove the tile table lookup entirely. That has resulted in faster tile rendering.

Unfortunately, 16-bit means that looping through the front/back buffer data is slower, as I have to increment each buffers' pointer twice now for each iteration. In fact, the program now runs around 25 to 30% slower.  :(
It seems like a lot, but... not only do the buffers take longer to step through now, but so do the comparisons between back/front buffer cells, as I have to check both high and low bytes now. Bummer.

I'll have a go at adding "tile sets" to the 8-bit version now. That might be a fix for the 255 tile issue, without such severe slowdown (I hope)!

Actually a "tileSet" table may not be a bad idea. It can be stepped through along with the front buffer, and I could use 4 bits for the set number (meaning I'd have up to 16 tile sets of 255 tiles each), and the other 4 bits could be used as flags to indicate thing like "platform", "deadly", etc.

Or I could have up to 8 sets of tiles (by using 3 bits) and therefore have 5 flag bits for tile types.
8 tile sets would allow for 2040 tiles, and would take (2040 * 16) = 32640 bytes.
Of course, RAM would be used up before that number of tiles was reached, so yes, I will limit the number of tile sets to 8.

Yes, I knew 65K tiles was not realistic, but it was fun to suggest it anyway...
what a nightmare to draw all those Pixel art tiles anyway.


on the other hand 256 tiles is not that small actually.


Many games don't use more than that per level.

Quote8 tile sets would allow for 2040 tiles, and would take (2040 * 16) = 32640 bytes.

clearly more than enough.


perhaps another solution would be to keep those tiles in 8bit, but just use like 2 or 3 tilesets, that would be used by some layers especially.
Some layers may share a common tileset, others not.


Just the place of those tilesets in RAM would indicate what layer it goes with/for... not sure if coding would work that way.
Many method can do the same result, but not exactly with the same CPU/RAM ratio I guess.


From what I learned when trying my hands at some JimPowers tiles, 256 is a bit limited, but 512 tiles is quite enough.
But yeay, gotta keep some place for sprites too.


You can also try with some 16x16 (mode1) or 8x16 (mode0) sized tiles but as you do a character based engine, this may also be quite a complication too.


Back to the engine.
It would be nice to have options to set the size of the whole tilemap (level design) and also to have some function to get a few layers (or even all) to cycle endlessly...
Like you know, meteors or clouds...


what is the current size of the tilemap ? (X and Y axis)


To limit it vertically or horizontally may gain a few things... I mean most paralax are by essence limited to horizontal or vertical only, just the other axis is somewhat limited (or not).


See Shadow of the beast, when you are "outside",  the vertical scrolling is quite limited, if even turned on...

Could you use a dirty buffer?
With 1 bit per tile?
You should know if the tile is dirty.. so you can mark it. No need for comparison..?
You could then also discard 8 tiles at the same time.

Also, you could mark an entire row as dirty or not discarding whole lines.

this may help.. it may not, depends on your design.

Quote from: arnoldemu on 08:44, 06 August 12
Could you use a dirty buffer?
With 1 bit per tile?
You should know if the tile is dirty.. so you can mark it. No need for comparison..?
You could then also discard 8 tiles at the same time.

Also, you could mark an entire row as dirty or not discarding whole lines.

this may help.. it may not, depends on your design.

Hmmm, that's an interesting idea.

The engine design revolves around current/previous buffer tile comparisons, but maybe I could put an intermediate step in there based on the dirty buffer idea.
My other program - Chunky Pixel Collision - relies on a dirty buffer for speeding up the display (amongst other things!), but that game design has large areas of emptiness on the screen, so it makes sense in that case.
This tile engine doesn't, but the number of comparisons could be reduced by checking a dirty buffer first... I'll try a few things out.

Thanks.

I had a look at your source, though my C is so rusty only bits and pieces stick out. :(


I'm interested in the Parallax Scrolling you've used cause you've got different parts of the image moving around different, unfortunately I wasn't sure which segments deal with the scrolling.


Have you seen David Hall's Space Storm II (ACU titled it: "Meteor Storm II")?
This 10-Liner features some amazing parallax scrolling moving a line at a time (in a small window). The routine I knocked up in the "Silly" thread is how I've dealt with generating a line by line effect, though it applies it in a physical way, so basically everything gets shifted down. I've gone into David's program numerous times and have been able to isolate where his Parallax Scrolling is, though his approach alludes me, and what he seems to have done is make a way to scroll the Stars and scroll the Rocks separately, and keep everything (e.g. his Alien Character) in it's current place.
I'm amazed that something so small can have me stumped. 8o

I haven't seen Meteor Storm II.
Sounds interesting!
I'll be hunting it down shortly...

Alrighty, this is (sort of) how the scrolling works.
- there are 4 layers: wallpaper, background, playfield and foreground.
- objects are placed within any of these 4 layers (and of course objects are made up of tiles).
- the layer determines the speed that something scrolls at.
- wallpaper doesn't scroll.
- background scrolls at half speed (i.e. 1 character square of movement every two frames).
- playfield scrolls at 1 character square per frame.
- foreground scrolls at 2 character squares per frame.

All that I do is determine (based on the above rules) where in the view window an object should be printed.
To be honest, I don't remember how it works!
I *think* it's something like this:
- wallpaper object's position is adjusted based on half the distance between it and a reference point.
position
- playfield object's position is adjusted based on the distance between it and a reference.
- foreground objects position is adjusted based on double the distance.

Something like that anyway!

Quote from: ervin on 00:36, 13 August 12
I haven't seen Meteor Storm II.
Sounds interesting!
I'll be hunting it down shortly...

I've attached the BASIC program on here before, but I'll attach the Disk Image cause it's a bit of a tricky program to track down all ACU 10-Liners were put into Disk Images. The bulk of this 3k game has been written in Assembly, though there is some BASIC interaction, and while the game isn't always completable, it's got that one more go factor about it and I've managed to complete it (without cheating).


Since I last wrote, I've managed to isolate one of the Scrolling Routines from this game which scrolls the stars down the screen, but it's all quite tricky, as I said earlier though it's a credit to David Hall to have been able to incorporate a Scrolling technique which deals with a certain object and specifically move it without worrying about anything else on screen being moved. Unfortunately the complexity of the Disassembly eludes me. I'll post the relevant code in here, so I hope someone can help interpret the routine.

QuoteAlrighty, this is (sort of) how the scrolling works.
- there are 4 layers: wallpaper, background, playfield and foreground.
- objects are placed within any of these 4 layers (and of course objects are made up of tiles).
- the layer determines the speed that something scrolls at.
- wallpaper doesn't scroll.
- background scrolls at half speed (i.e. 1 character square of movement every two frames).
- playfield scrolls at 1 character square per frame.
- foreground scrolls at 2 character squares per frame.

All that I do is determine (based on the above rules) where in the view window an object should be printed.
To be honest, I don't remember how it works!
I *think* it's something like this:
- wallpaper object's position is adjusted based on half the distance between it and a reference point.
position
- playfield object's position is adjusted based on the distance between it and a reference.
- foreground objects position is adjusted based on double the distance.

Something like that anyway!

Seems to be a credit to you to be able to generate several things happening at once. I've never seen so many Variables & arrays, it reminds me of Codies Wizard Willy, which has all this stuff in the foreground and a slower moving background, the border thing you have happening there is also like the effect generated in Wizard Willy with the yellow status graphic which sits around the rest of the screen. Only difference is WW doesn't Scroll Up or Down, though you can move from Left to Right and Right to Left back to the Beginning of the Level.

Wow - Space Storm II is very impressive for a type-in!
Nice and smooth.

Yeah, I do use a lot of variables. There are a lot of things going on in the background, and I tried to reduce the number of variables, but that would generally result in more complicated code, so I decided to keep 'em.
:)

Wow, that is lovely, though very hard! Impressive scrolling...

Quote from: CP/M User on 07:15, 13 August 12

Since I last wrote, I've managed to isolate one of the Scrolling Routines from this game which scrolls the stars down the screen, but it's all quite tricky, as I said earlier though it's a credit to David Hall to have been able to incorporate a Scrolling technique which deals with a certain object and specifically move it without worrying about anything else on screen being moved. Unfortunately the complexity of the Disassembly eludes me. I'll post the relevant code in here, so I hope someone can help interpret the routine.

Maybe the problem is thinking of it as scrolling?  ;)  It's all "sprites".  There's a main loop between &2730 and &275c.  At the beginning it makes a series of calls.  Call &275e moves the meteors down a line, Call &27f6 moves the stars down a line, and Call &2861 handles the player.  Call &275e is there twice in the loop, so there's your parallax effect.  You can see they are sprites by breaking from the program, putting junk text on the screen and typing Call &275e.


[EDIT]


Just had a quick look at the routine at &275e, it looks like the meteors are governed by a table starting at &3e81, taking the form of a y co-ordinate and then a screen address for the top left hand corner of the sprite. The value at &3e80 is used as a counter to the next meteor.  Broadly speaking, the first thing it does at &275e is check the counter to the next meteor, and the code that follows is for creating a new meteor if the counter has reached &1A.  From &2785 the routine does it's main loop of printing meteors.  This first checks for meteors that dont exist (y=0) or need clipping at the top or bottom, but if it gets to &27a8 it is going to print a whole meteor.

Quote from: Axelay on 11:45, 13 August 12

Maybe the problem is thinking of it as scrolling?  ;)  It's all "sprites".  There's a main loop between &2730 and &275c.  At the beginning it makes a series of calls.  Call &275e moves the meteors down a line, Call &27f6 moves the stars down a line, and Call &2861 handles the player.  Call &275e is there twice in the loop, so there's your parallax effect.  You can see they are sprites by breaking from the program, putting junk text on the screen and typing Call &275e.


[EDIT]


Just had a quick look at the routine at &275e, it looks like the meteors are governed by a table starting at &3e81, taking the form of a y co-ordinate and then a screen address for the top left hand corner of the sprite. The value at &3e80 is used as a counter to the next meteor.  Broadly speaking, the first thing it does at &275e is check the counter to the next meteor, and the code that follows is for creating a new meteor if the counter has reached &1A.  From &2785 the routine does it's main loop of printing meteors.  This first checks for meteors that dont exist (y=0) or need clipping at the top or bottom, but if it gets to &27a8 it is going to print a whole meteor.

:laugh:  yeah maybe the problem is "it's not scrolling", magazines like ACU & AA were using the term Parallax Scrolling to describe David Hall's (Space Storm II & Space Storm 3) games.


I've been looking at the bit of code which displays & moves the stars around at &27F6 which isn't quite a complicated, this is what I extract from it. I hope I don't offend anyone or David Hall. I was going to start up a new thread, but since I opened the can of worms in here I'll post it here, sorry Ervin.


      org &2000


      ld hl,&3a98      ;; This is storing something here and moves down to
      inc (hl)      ;; &3AFB
      ld a,(hl)
      cp &06
      jr nz,movestars
.genstar   ld (hl),&00      ;; this section must deal with randomly drawing a star
      ld hl,&3a96      ;; to screen
      ld de,&0003     
.makemore   add hl,de      ;; I'm guessing this will make more
      ld a,(hl)
      cp &00
      jr nz,makemore
      ld (hl),&01
      ld a,r         ;; The R Register can be used as a way of making something random
      ld b,a
.wasnocarry   xor a
.bisnotzero   inc a
      cp &2d
      jr nc,wasnocarry
      djnz bisnotzero
      inc hl
      ld (hl),a
      inc hl
      ld (hl),&c8
.movestars   ld b,&24
      ld ix,&3a99
.mainloop   ld a,(ix+&00)
      cp &00
      jr z,iszero
      ld h,(ix+&02)
      ld l,(ix+&01)
      ld a,(hl)
      cp &20
      jr nz,toscroll
      ld (hl),&00
.toscroll   call movestuff
      ld (ix+&02),h
      ld (ix+&01),l
      ld a,(hl)
      cp &00
      jr nz,notzero
      ld (hl),&20
.notzero   inc (ix+&00)
      ld a,(ix+&00)
      cp &c5
      jr nz,iszero
      ld (ix+&00),&00
      ld (hl),&00
.iszero      ld de,&0003
      add ix,de
      djnz mainloop
      ret


.movestuff   ld a,h
      add &08
      ld h,a
      cp &c0
      ret nc
      push de
      ld de,&c050
      add hl,de
      pop de
      ret



It takes some time to get going, I found when I call &2000 it didn't do anything, but if I put it into a loop


mode 1:for a=1 to 2000:call &bd19:call &2000:next a


that should get it going. Though I was hoping that bit of assembly could be explained cause I'm having trouble understanding it. :(