News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu
avatar_ervin

character-based tile engine with parallax scrolling

Started by ervin, 03:41, 01 August 12

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

ervin

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.

TFM

That's actually really well done, the speed is way better than expected  :)
TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

endangermice

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!
For all the latest Starquake remake news check out my website - www.endangermice.co.uk

ervin

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.

MacDeath

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 ?

ervin

 :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!  ;)

MacDeath


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


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


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


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)


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.


ervin

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.

ervin

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.
:)

MacDeath

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

Irem's R-TYPE on the MSX - Stage 6


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.

ervin

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.

MacDeath

#11
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

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


(just asking)

ervin

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.

MacDeath

#13
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.

ervin

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).

TotO

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...
"You make one mistake in your life and the internet will never let you live it down" (Keith Goodyer)

arnoldemu

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.
My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

arnoldemu

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.
My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

ralferoo

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

ervin

Thanks ralferoo.

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

AMSDOS


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?
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.
* Using the old Amstrad Languages :D   * with the Firmware :P
* I also like to problem solve code in BASIC :)   * And type-in Type-Ins! :D

Home Computing Weekly Programs
Popular Computing Weekly Programs
Your Computer Programs
Updated Other Program Links on Profile Page (Update April 16/15 phew!)
Programs for Turbo Pascal 3

joska

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.

ervin

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.  :)

Xifos

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 !
:)

AMSDOS


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! :(
* Using the old Amstrad Languages :D   * with the Firmware :P
* I also like to problem solve code in BASIC :)   * And type-in Type-Ins! :D

Home Computing Weekly Programs
Popular Computing Weekly Programs
Your Computer Programs
Updated Other Program Links on Profile Page (Update April 16/15 phew!)
Programs for Turbo Pascal 3

Powered by SMFPacks Menu Editor Mod