Hi folks.
Since completing my cpctelera line-drawing package last year, I've not done any coding.
But that itch never goes away, and I've decided to pick up the compiler once again.
:laugh:
Anyway, a few years back I wrote a tile-based engine using ccz80, but only used it for a simple demo.
It ran quite well, but I've learned a lot since then (and of course RUNCPC used a tile-based display)...
So I thought I'd write a tile-based side-scrolling platformer using cpctelera.
So far there is no scrolling. Or platforming.
But there are tiles, and the screen display routines are done, and I'm seeing some nice possibilities.
Hopefully I'll manage to finish a game with it (even something simple!).
I can imagine a full-screen game running quite quickly with this engine, though obviously it's a little early to tell!
I'm hoping to have quite a zoomed-in viewpoint, with a large main character.
The first attachment is simply a box that can be moved around the screen using the arrow keys, but it gives a good idea of the speed.
Note that while the screen display routines are optimised, nothing else is.
(i.e. the positioning of the squares and the tiles of the box itself are done using C, not asm).
Note that I have no idea how to use hardware tricks and crtc registers or any of that stuff.
This is all done in software, and uses a dirty buffer approach, to achieve a high speed display.
Also, I want this to run on a 464, and I'll probably need as much RAM as possible, so no double-buffering.
This of course results in a bit of screen-tearing, but to be honest I kind of like it!
:P
It actually looks very cool!! Can I encourage you to go for a 128KB version as well? :)
Quote from: ||C|-|E|| on 13:04, 21 April 17
It actually looks very cool!! Can I encourage you to go for a 128KB version as well? :)
Thanks!
:)
I'll have to think about that... spare time is hard to find, so I'll have to see how the "464 version" comes along.
It's nice to see new projects made with CPCTelera, it's rather quiet these days.
Good technical demo, the animation is quite smooth.
Hi everyone.
I've uploaded a new file to the first post (dshadow_1.zip).
Left/Right makes the red square move left and right, and SPACE causes it to jump.
I'm curious what folks think of the rudimentary physics I've put in for the character control.
I've deliberately followed Jet Set Willy's jumping style:
- jumping up causes the character to go up, and no sideways movement is allowed
- jumping sideways locks you into that jump - you can't deviate from the jump until landing
Please have a quick try and let me know what you think.
:)
Next up, I'll start work on basic interactions with a collision map.
Quote from: ervin on 11:34, 21 April 17
Note that I have no idea how to use hardware tricks and crtc registers or any of that stuff.
This is all done in software, and uses a dirty buffer approach, to achieve a high speed display.
But I thought the moment you've ditched the Firmware, you have to rely on the Hardware? ???
Quote from: AMSDOS on 10:27, 05 May 17
But I thought the moment you've ditched the Firmware, you have to rely on the Hardware? ???
Nope, all done in software.
:)
The firmware allows you to access hardware features, like scrolling and stuff like that (please correct me if I'm wrong), and of course you can access hardware features without the firmware. But I'm only using SDCC (with a number of cpctelera functions), and asm for the tile display routines, and dirty buffer management.
The thing I *really* love about cpctelera is that it allows me to ditch the firmware (thereby freeing up A LOT of RAM), while also providing *fast* functions (that do things the firmware might do, or optimised versions of standard C functions). And during compilation it only includes the functions you've used, thereby saving memory.
Quote from: ervin on 11:33, 05 May 17
The thing I *really* love about cpctelera is that it allows me to ditch the firmware (thereby freeing up A LOT of RAM), while also providing *fast* functions (that do things the firmware might do, or optimised versions of standard C functions). And during compilation it only includes the functions you've used, thereby saving memory.
It seems like it's also disabling the DOS as well as the firmware as different addresses are assigned to Disc Management while others relate to values the Firmware needs to return. That's the impression I got when I look at the Firmware manual. The Firmware Jumpblock is only small by comparison as it points to the ROM to perform the set task.
The jump effect is good, curious to see what you'll do with it.
Quote from: Arnaud on 13:38, 05 May 17
The jump effect is good, curious to see what you'll do with it.
Thanks.
;D
The little square is just a test; I'm planning to use a much bigger character, but as I've never written a platformer before, I thought I'd start with something very small and simple.
Quote from: AMSDOS on 13:17, 05 May 17
It seems like it's also disabling the DOS as well as the firmware as different addresses are assigned to Disc Management while others relate to values the Firmware needs to return. That's the impression I got when I look at the Firmware manual. The Firmware Jumpblock is only small by comparison as it points to the ROM to perform the set task.
A few years ago, when I was writing Chunky Pixel Curator in ccz80, I had lots of issues with running out of RAM.
My programs couldn't go past &A6FC (presumably because that would start trashing the firmware?).
Anyway, when I disable the firmware in cpctelera, I can use all the RAM up to &BFFF, right before the vid memory starts.
Now, I believe the stack starts there and grows downwards, so that needs to be taken into account (though cpctelera makes it easy to move the stack).
Anyway, disregarding the stack, the space from &A6FC to &BFFF (inclusive) is 6,404 bytes, which is a lot considering the total memory in the CPC.
That extra 6K+ would have been *so* useful back when I was using ccz80.