enJine: a fast tilemap engine
tile engine based on excellent work by Joffa Smifff. here you can download first tech demo.
Get It Now!
enJine can be used to create fast games like Cobra or FireFly. with careful level design and optimizations for the needs of the game one can have 25-fps smooth scrolling with almost full frame free for sprites and game logic.
althru this demo works in 48K mode, the enJine written with 128K machines and shadow screen using in mind (so programmer can print many flickerless sprites).
enJine sources will be released after i finish my top-secret game based on this code.
of course you can disasm enJine and try to use it as is. %-)
and don't be fooled by simplicity of the demo: you can do many cool things with enJine!
p.s. if you really want to use enJine for your game right now, don't hesitate to contact me. %-)
p.p.s. enJine is not yet optimized for speed, i surely will squeeze some more ticks in final release.
Get It Now!
enJine can be used to create fast games like Cobra or FireFly. with careful level design and optimizations for the needs of the game one can have 25-fps smooth scrolling with almost full frame free for sprites and game logic.
althru this demo works in 48K mode, the enJine written with 128K machines and shadow screen using in mind (so programmer can print many flickerless sprites).
enJine sources will be released after i finish my top-secret game based on this code.
of course you can disasm enJine and try to use it as is. %-)
and don't be fooled by simplicity of the demo: you can do many cool things with enJine!
p.s. if you really want to use enJine for your game right now, don't hesitate to contact me. %-)
p.p.s. enJine is not yet optimized for speed, i surely will squeeze some more ticks in final release.
Post edited by Ketmar on
Comments
tnx. %-)
>whats this game your working on then?
it will be adventure shooter in the style of Rex/Myth and FireFly (sometimes you will control something like space ship and sometimes a walking hero). i'm still experimenting with Speccy limits though, so game script is not complete yet. there will be some b...rds to kill with your Big Guns and some adveture-like puzzles to solve, the things I always wanted to see in one game.
besides this, i'm a coder. i can't do music, i can't do graphics. and i'm lazy moron too, so i don't want to ask someone do artwork for me just to dump it due to lazyness. enJine demo was ready weeks ago, but i was sitting and dreaming about how i'll do it visually stunning and get thousands of 'WOW!'s. and then i forced myself to release it 'as is' -- just to have something released finally (for me it's really hard to actually release things 'to the wild': i'm always thinking that 'i just should make some last touches...').
so i'm seriously thinking about releasing enJine sources sooner than the game. i still have to write documentation and some tools, there is alot of thins that should be automated.
and of course i have some ideas how to make it even faster, it's always good. %-)
use this in any way you want (if it is usable at all).
code: Joffa and me. %-)
license: i don't know. probably public domain. %-)
assembler: my own. but i think it can be easily adapted for pasmo or sjasm.
ah, i nearly forgot the link. %-)
i don't think that it is of any use for anybody except me, but sure i can publish it. it's just like my other programs: ugly C and excellent documentation squeezed into exactly 0 bytes.
here.
it will not work on machines without proper #FF port.
the trick is the same Joffa used in Cobra: do some work before crt ray reaches the screen (while it draws nothing or upper part of border). then draw map (ray draws the screen faster then we blitting map, so no shearing), and then we have ~14000 ticks to draw sprites and alot of time in 2nd frame to do game logic.
the code is dirty and based on 1st demo, but if you want to see it — just ask.
putting helicopter sprite takes ~1900 t-states for just LD and ~2700 t-states for ORed sprite (for fast memory). sprites are zig-zaged and loading with POP.
the bad thing is that we can miss one interrupt, so we can't play AY music here. still working on it (interrupts must be disabled for map blitting due to stack usage, and there is no way to detect 'missing' interrupt -- only make blitters 't-state-stable').
p.s.: does anybody interested in this at all? i'm making noise here without any real feedback (only kgmcneil answers, tnx %-). if nobody interested in such engine for forthcoming games, i'll just stop noising and will publish only sources for new versions of engine.
p.p.s: if anybody interested: my assembler. windoze build is NOT TESTED. sources included, binaries included. sources are PD/WTFPL.
Hey! The engine is very interesting, and is definitely an achievement. Well done! Looks good to me.
Is it interesting to me? A time-critical engine itself is not very useful if I can't use it to display sprites without flicker (unless you want everyone else digging into your code).
Personally I don't need scrolling to make games, but if I need one it would be 28*16/18 chars, full colour 25 fps, horizontal scrolling only, with some sprites, like the one in stormlord.
What you're doing now is a technical demo, but isn't very usable yet. It is still interesting to post demos of it, so that we (and you) know how far you are with the game, because it will still take some time before it will be a real game.
To be honest I don't know what to say other than "interesting" right now. Is that what you want?
Games List 2016 - Games List 2015 - Games List 2014
>sprites without flicker
you can display 6–8 sprites 32x16 w/o flicker. %-)
for only one screen we have to count times, alas.
and i can add attr scrolling, i just don't need it.
>What you're doing now is a technical demo, but isn't very usable yet.
yes. i'm developing tools to build levels, etc. i'll show 2px/attr scroller soon in Fort Apocalypse port.
>Is that what you want?
yes. i want to see someone who want to use this engine. then i'll write tools to use it, documentation, etc.
>What you're doing now is a technical demo, but isn't very usable yet
hm. my tech demos are usable for asm programmers.
>with some sprites, like the one in stormlord
stormlord is easy. %-) should i do stormlord demo to show enJine capabilities? %-) actually, SL is easier than my engine blitting.
actually, i'm asking about another thing. ?should i tell how i did some things i did in another demo?? there is alot of reaction on 50Hurts (it's cool, really cool, just believe me). but i see that nobody wants to know how we can do 25fps scrollers for 48k.
i'm always publishing the sources — i blieve the sources will be usable for all programmers.
but i don't want to describe tech i used for blitting, etc — if nobody wants to read about this.
I know. SL is easy. Should you do a SL demo to show anyone else? Yes, if you want to attract other people.
50hurts is new. 25fps 2/3 screen scrollers in 48k is not new, I think.
I personally don't think I need any documentation to make an engine like this, but I'd say other people might be interested in it.
Games List 2016 - Games List 2015 - Games List 2014
and no fast scrolling games. i'm really tired of flip-screen platformers.
>Should you do a SL demo to show anyone else? Yes, if you want to attract other people.
but it will not show the capabilities of enJine -- enJine is for another kind of games.
>I personally don't think I need any documentation to make an engine like this
and then why we have alot of flip-screen platformers with sp3 (the only difference is tile graphics) and no things like Cobra or Firefly?
p.p.s: if anybody interested: my assembler. windoze build is NOT TESTED. sources included, binaries included. sources are PD/WTFPL.[/QUOTE]
Hi
I am very interested in how this works. Knowing the capabilities of the machine the demo is great. For me knowing how it works and looks at the way in which it is coded is the most interesting part of these achievements. The way in which these new "cannot be done" routines keep popping up is amazing.
Keep up the good work and looking forward to seeing how you achieved this and hopeully a discussion on how this can evolve in the future.
Cheers
M
As a follow up, can I ask what machines\emulators this will work on flawlessly as I have just tried your latest demo on my emulator setup and it flickers like mad in places (most probably because, as you say, "it will not work on machines without proper #FF port"). Will a game written with this engine only be able to run on specific hardware or software, and if so what?
there is nothing new really — it's the thing Joffa did years ago. i'm not pretending to discover something new.
here you can get sources for the 2nd demo.
there is no tools for this engine yet — i'm still developing it. but it *will* have level editor, dox, etc in the future. for now — feel free to ask me any questions, i'll try to explain everything i can.
basically, you have ~2/3 frame for game logic (i'll try to explain this later) — a lot of time, i think.
also, i'll release 'draw map and write logic' tools for it. for now i just want to know if anyone is interested in this. if yes, i'll rewrite it for pasmo/sjasm and do tools/dox.
>can I ask what machines\emulators this will work on flawlessly
it works perfectly in FUSE in 48K/128K mode. basically, it should work ok in any emulator that correctly does port #FF and timing (including contended memory) and on the real hardware.
>it will not work on machines without proper #FF port
it's a feature of the demo, engine itself doesn't care. port #FF used for crt ray syncing, 'cause demo hasn't alot of action to compensate unused t-states.
>Will a game written with this engine only be able to run on specific hardware
any standard 48k/128k shell do. if you will be able to squeeze logic in two parts: 'before crt ray' and 'after crt ray' — the game will work on any spectrum. for 128k there will be some 'cheating' that will allow to use almost full frame for game logic — due to virtual screen swaping.
p.s. the one thing that complicates the whole process is that i'm really bad in English (as you can see reading my posts).
2) Yes, there is interest in this, but as Turkwel has hinted, there would be more interest if this was done with some tools and/or documentation... YES, we WOULD love to see this translated to something like Pasmo/Sjasm, or something standard... I for one, would be thrilled to add this to my software library, to consider using for when the creative impulse impells me to write something, as would other beginner programmers out there.. :)
3) From my own point of view (as one who is learning to program z80), it doesn't matter that this has been done before - what matters to me is the fact that it is only now becoming accessible and available, and that without people like you contributing, this area of programming would would remain a mystery to beginners such as myself...
Thanks,
Keep up the Good Work ;)
there WILL be tools and dox, i promise! %-) for now i just wanted to show some tech demos. i hope that after releasing 'final' any programmer that is not z80-geeky can write a game using this enjine — 'cause i really want more scrolling games! %-)
but i don't think that enJine will be usable with z88dk, sorry. it needs some 'strict' memory mapping.
>as Turkwel has hinted, there would be more interest if this was done with some tools
>and/or documentation… YES, we WOULD love to see this translated to something
>like Pasmo/Sjasm, or something standard
it's not so hard, actually — my assembler has almost no 'non-standard' features. the only thing is 'local labels', and i'm sure that either pasmo or sjasm (+) has this feature too.
I checked out your first thing and it looks promising.
I'm interested in looking at this now more in depth.
There is some strict memory mapping for sp1 too -- this is done using a config file that defines fixed locations of some data structures. The user can redefine the locations of the data structures (subject to restrictions) and then recompile the library. We can do something similar for enJine.
If you get it to a point that it's near finished, I have no problem taking it the last step so that it can be used with z88dk. z88dk will allow it to be used from asm or C or a mixture. From what I have seen I don't think C will be a problem -- any low level requirements can always be autogenerated from high level specs (such as generation of push/pop sequences from spriet data which is then present as an address in C).
Don't be shy in providing different versions or configurations for 128k / 48k / colour scroll / fixed N-bit scroll, etc. if it makes sense :-)
Write games in C using Z88DK and SP1
enJine, in contrary, redraws the *whole* playing area each time, with pre-built 'pushers', so it in no way can draw 'sparse' maps with the same speed as stormlord engine does. but it can draw map full of tiles with very marginal speed loss (and it can do background parallax, i just don't like it).
i'm not telling that stormlord is badly written (it does it's job after all %-), it's just *very different* engine. so don't expect to write 'stormlord 3' with enJine (althru 'cobra 2' is definitely possible %-).
That's very true - I remember looking at the code for Stormlord shortly after it came out and did some little demos and found the same thing. Good for R-Type style games though where variety in the tiles is key. I suspect Zynaps is similar.
I'm just back on WoS after something of a hiatus and was very surprised to see you working on very similar ideas to myself! I'm also in the middle of coding a scrolling engine similar to Cobra but hoping to add a bit more flexibility. At the moment it's a lot of bits of code and I'm planning on tying things together over the next couple of weeks to get something tangible working. I loved seeing the chopper from Fort Apocalypse appear in your second demo - That was one of the few games I really enjoyed on the C64 and it would be nice to see your take on it.
Schedule-wise, my own problem is I'm working on a dynamic tiling engine at the same time and kind of getting distracted, but it's just the way I work and things are coming together now. The plan is to have a huge play area without wasting loads of memory on a map that you're only seeing a little part of. I'm quite ambitious for this project and think it might end up being a 128k game but I'm trying to keep it within the 48k model. I was hoping to have something ready to mark Joffa's passing but I don't think that's gonna happen now.
Please keep us updated on your progress, I'm interested to see how you get on! Feel free to PM me if you think it might be helpful to share ideas as I think we have the same idea on the gameplay.
you caught me! %-)
yes, i'm planning to port Fort Apocalypse to show off some enJine capabilities. i'm busy with other things now, but i hope to return to Speccy soon. %-)
>The plan is to have a huge play area without wasting loads of memory on a map that
>you're only seeing a little part of
that would be cool. enJine uses 64x64 map with one byte descibing two tiles (so it wastes 2048 bytes on map, even if the map itself is full of empty spaces). i'm thinking about Really Big Map made of pieces that unpacks as the player reaches 'piece edge', but this will ruin smooth movement (at the edge).
plus, enJine needs 1536 bytes for one tileset (12 tiles, 4 preshifted tilesets). increasing number of available tiles is not hard, but it will eat memory like a hungry Horace. %-) oh, and there is some limitation on tiles placement.
but for 128K this is not so limiting: i can use page full of graphics to draw the screen, and then i have one intr when i don't need any graphics, so i can switch that bank to code.
Likewise. I've been working on this for some time now but have been hard pushed to put the time into it. I've got a lot of the thinking out of the way now though so the code is starting to form. At the moment I'm using the Windows version of Zeus Assembler to make the binary and I either test it in an emulator or transfer it through the serial port to the Speccy. I'm hoping to have a productive weekend this week and tie a lot of stuff together.
Oh yes, I know what you're talking about. I'm actually sticking with the grouping of 3 tiles myself as it makes the most sense when you need a left tile, a repeatable middle tile and a right tile. At the moment I'm working on a limitation of 7 different tiles per row (possibly 8 if I decide to use AF' - It all depends on how complex the map gets) as you probably are too but I'm hoping to have the display routine interrupt driven and have the non-critical code generating preshifted tilesets as they are triggered throughout the map; The preshifted tilesets will effectively be streamed into working memory as they're needed.
The same will go for the sprites if I can keep the speed up. I actually see the sprites as being the worst job ahead as they also have to have a mask (I don't think I'll get away with none when they overlap, it'll just look too messy) and each frame of animation has to have its own set of preshifted versions ready to use.
My code is using a wraparound map of 32 x 16 tiles and the map will be stored as 8 x 8 chunks. As the viewport scrolls around the map, the non-visible part will be updated from a compressed version of the whole map. I have a few ideas on how these map chunks will be compressed and have to try them out to see which works best for an actual playable map (rather than a best-case scenario). I haven't timed the code to do this yet but it shouldn't be too heavy on cycles.
I think I should be OK on memory and right now it's more a case of wondering if I'll have too few CPU cycles left over and need the display paging of the 128 to prevent flicker. Fingers crossed this shouldn't be necessary because if I go the 128k route I'll feel obliged to do sound effects too!
>I either test it in an emulator or transfer it through the serial port to the Speccy
i'm using my own assembler (ah, it's easy to write toolchain, and it's hard to read other's dox %-) and have no real Speccy at all; so i'm testing the code in FUSE.
>I'm actually sticking with the grouping of 3 tiles myself as it makes the most sense
>when you need a left tile, a repeatable middle tile and a right tile
me too. 4 rows by 3 tiles.
>but I'm hoping to have the display routine interrupt driven
the hard thing is that i can't start screen output when interrupt comes, 'cause it causes screen shearing (you can see that in the first demo). i have to wait ~14000 t-states (i can do some game logic there) and then start screen drawing, to allow flicker-less sprite output. for 128K i can use shadow screen, but then i can't use page switching for code/graphics part. why, oh, why we can't have two separate page banks?! %-)
>I actually see the sprites as being the worst job ahead as they also have to have a
>mask
isn't it possible to just 'or' the sprites? if your map has no detailed backgrounds (as the one in my demo), then you can use 'or'. but this definitely can't be a choise for the game like 'cobra', where sprites overlaps with non-empty tiles.
but this is perfectly acceptable for a game like Fort Apocalypse (actually, i can just copy bytes, 'cause sprites in FA doesn't overlap at all).
>Fingers crossed this shouldn't be necessary
good luck! i want to see some demos! %-)
btw: you can download sources of my 2nd demo, if you are interested. but it's not easy to read. %-)
Yeah, I know what you mean, I know Joffa made extensive use of port 255 for doing useful stuff while the code was waiting for the beam to go past. I think he also updated the 50fps scrolling ground in that space too (which was a great trick as it makes the scrolling of the rest of the display look super-smooth, he did that with Hysteria as well). I think there should be plenty of fixed-duration code that can be put in there, like you say the game logic.
It is a bit of shame about the 128's bank switching, you'd think they would have made it bit more flexible, you'd have to do quite a bit of shuffling around just to try and keep the important stuff in page 2 (unless you duplicate your code in the last 9k of banks 5 and 7, or interleave it so that code that happens on odd frames is in bank 5 and code for the even frames is in bank 7)
I don't think it'll work for the game design I have in mind. I don't plan on having sprites placed over tiles but there will be some places where background tiles are going to be used and I have some sections planned where there will be a lot of overlapping sprites running around. It would make the sprite routines a hell of a lot quicker though...
I did have a look at your sources after my last post but I think I'd probably spend too much time working it out and might end up confusing myself as to what I was working on! ;-)
- IONIAN-GAMES.com -