Hi everyone.
After a heck of a long time, I am finally able to show you all what I've been working on.
I'm *really* excited about other people trying it and giving me feedback (good, bad or indifferent - it's all ok)!
(I've been working on this since the end of 2010, although it has changed form a few times).
It's not a game as such, and I'm sure that some people may not enjoy my program, but that's cool.
It means a *lot* to me, and I'm very proud of what I have achieved thus far.
8)
Now, it is important to note that, whilst feature-complete, it isn't ANYWHERE NEAR content complete yet.
The final version will have up to 250 rooms, while this teaser only contains the first 2 rooms.
However, I have written tools to create the necessary data files for the other rooms, so content should be added at a fairly decent pace.
When you run CPC.BAS, and after it has loaded, please follow the information on-screen to find out what to do.
;)
Some technical info:
- written in CCZ80 and assembly
- only the first 64KB is used
- I've used a double-buffered 32x32 char screen
- compressed data (via Exomizer) is used extensively, and loaded from disc as needed (i.e. when changing rooms)
- the stack is abused on an extremely frequent basis
- the amount of self-modifying-code is truly terrifying!
- the program would run a little faster if I didn't wait for VBL, but that would introduce a bit of flickering
All of the following features occur in real-time:
- the position of each chunky sprite (which can be full-screen) is calculated in 3D space
- sprites are clipped to the left/right edges of the screen as necessary
- sprites can be flipped horizontally
- sprites can be animated
- sprites are scaled depending on distance from the camera
- room walls and doors are calculated in 3D space and drawn using a variety of line techniques
I hope you enjoy my little tribute to the CPC.
Please remember that this is only a tiny teaser - there is lots more to come!
Awesome! It made me smile :D
Amazing, can't wait to see this develop. I'm guessing this is going to be "tour" of sorts through the history of the CPC (am I right?)
Roland working that pole (er, I mean rope :laugh: ) cracked me up.
Boooo!
It crashes using Arnold on OSX. will have to wait until I get home tomorrow to test it on a real CPC
Wow! That's another cool way to make a 3d game on CPC. I really liked that!
Thanks everyone for your kind words - I'm glad others are enjoying this crazy idea of mine. [emoji4]
@CraigsBar - I'm not sure but my program may not work on a 464. Which CPC model do you have Arnold set to?
I haven't used any fancy hardware tricks (except for the 32x32 char screen, and the double-buffering), primarily because I don't know how to. [emoji41]
Oh WoW! Great work! You got half the castle wolfenstein engine!
Such a Gallery is really funny. And from the technical aspect ... Kudos!
Maybe the Sound can be adapted to the walking speed. So when walking quick (5) then the sound could be more quick than when walking with low speed (1).
It runs fine with WinApe, not with WinCPC. But that's a problem of the emulator developers.
Keep the great work going Ervin!!! :) :) :)
Wow, I've just had lunch at my parents' house, and we were showing my daughters some photos of when I was a boy. And guess what we found? Photos of me in front of my cpc464, working on a type-in from ACU! It was a wonderful reminder of why I am writing this program... Priceless memories.
Quote from: ervin on 00:53, 16 November 14
@CraigsBar (http://www.cpcwiki.eu/forum/index.php?action=profile;u=482) - I'm not sure but my program may not work on a 464. Which CPC model do you have Arnold set to?
If you're only using 64K, why wouldn't it work on a 464, unless you're using something specific to firmware 1.1?
Quote from: ervin on 00:53, 16 November 14
I haven't used any fancy hardware tricks (except for the 32x32 char screen, and the double-buffering), primarily because I don't know how to. (https://s3.amazonaws.com/tapatalk-emoji/emoji41.png)
Oh, well I think there's a good chance that's more fancy hardware trickery than a majority of commercial era software. ;)
Quote from: Axelay on 04:26, 16 November 14
If you're only using 64K, why wouldn't it work on a 464, unless you're using something specific to firmware 1.1?
Hmmm, sounds like I may need to do some testing and research!
(But first I'll try it on WinAPE in 464 mode).
Quote from: ervin on 00:53, 16 November 14
Thanks everyone for your kind words - I'm glad others are enjoying this crazy idea of mine. [emoji4]
@CraigsBar - I'm not sure but my program may not work on a 464. Which CPC model do you have Arnold set to?
I haven't used any fancy hardware tricks (except for the 32x32 char screen, and the double-buffering), primarily because I don't know how to. [emoji41]
Hi ervin,
It more likely an osx Arnold bug. The port looks very polished but it has some issues and seems to have been abandoned (it was not done by @arnoldemu). I am sure an official Arnold port for osx will not have these issues.
Craig
Hmmm, interesting.
Regardless, it turns out I do indeed use a call to a non-464 function. Oops. I'll sort it out and upload a new version shortly.
Alrighty, I was using the CCZ80 FRAME() function, which of course refers to the 6128 rom.
I've replaced it with a call to MC WAIT FLYBACK, and things now work in WinAPE when I set the roms to OS464 and BASIC1-0.
I also fixed a silly bit of flicker that could happen when changing rooms.
I've updated the DSK file attached to the first post in this thread.
However, WinCPC crashes hard when I walk into the Roland room.
I don't know if this is because my program is broken, or doing something incompatible with my setup in WinCPC (it's a clean install, I've just changed the CPC model).
I'd like to ask a favour (actually 3) from anyone that can help.
- can someone please try this new version on a real 464 with disc drive?
- a real 664
- a real 6128
Thanks.
:)
Quote from: TFM on 01:23, 16 November 14
Oh WoW! Great work! You got half the castle wolfenstein engine!
Such a Gallery is really funny. And from the technical aspect ... Kudos!
Maybe the Sound can be adapted to the walking speed. So when walking quick (5) then the sound could be more quick than when walking with low speed (1).
It runs fine with WinApe, not with WinCPC. But that's a problem of the emulator developers.
Keep the great work going Ervin!!! :) :) :)
Thanks for the kind words TFM.
I'm especially happy with the technical aspects - my z80 has improved a heck of a lot in the last few years!
I'm afraid I can't change the way the sound is done. :(
Not because it isn't possible, but because it wouldn't suit my plans for each room.
Have a listen to the "music" that plays when you walk around the Roland room. Do you recognise it? 8)
Quote from: Morri on 18:46, 15 November 14
Amazing, can't wait to see this develop. I'm guessing this is going to be "tour" of sorts through the history of the CPC (am I right?)
Roland working that pole (er, I mean rope :laugh: ) cracked me up.
Yes indeed - it will be a gallery!
The comedy associated with Roland climbing the rope was unintentional, but too funny to remove! So it stays. :laugh:
Quote from: ervin on 14:18, 16 November 14
However, WinCPC crashes hard when I walk into the Roland room.
That is EXACTLY where OSX Arnold also crashes.
Testing on my 4128plus right now....
The same crash on my 4128plus
Oh, AND on my CPC 6128 machine :(
Time for Winape methinks.
Quote from: CraigsBar on 00:45, 17 November 14
That is EXACTLY where OSX Arnold also crashes.
Testing on my 4128plus right now....
The same crash on my 4128plus
Oh, AND on my CPC 6128 machine :(
Time for Winape methinks.
Thanks for the info... hmmm, this is gonna be tricky to fix.
I have absolutely no idea what could be causing the crash... the things that happen on a room transition (which is where the crash would be) happen when the empty start room (the foyer) is loaded, so I don't know why the Roland room would cause a crash, as the same code is being run.
Time to bust out the debugging stick!
This is very, very original and very pleasant... Can't wait to see more!
Won't you implement turning instead of only strafing?
@erving , any chance for a scan of those photos? :)
Quote from: Gryzor on 15:46, 17 November 14
This is very, very original and very pleasant... Can't wait to see more!
Won't you implement turning instead of only strafing?
@erving , any chance for a scan of those photos? :)
Thanks Gryzor.
I had toyed with the idea of turning (months ago), but in the end went with simple strafe movement, as it simplified a lot of things (line routines, 3d calculations, collision detection etc.), and that means SPEED! 8)
(I've been expecting that exact question, actually).
Yep, I'll upload those photos soon (even though they are rather embarrassing).
Alrighty, I've found the section that is causing WinCPC (and presumably a real CPC) to crash.
Dunno why though...
Strange that it works fine in WinAPE. :o
Quote from: ervin on 23:39, 17 November 14
Alrighty, I've found the section that is causing WinCPC (and presumably a real CPC) to crash.
Dunno why though...
Strange that it works fine in WinAPE. :o
It was working fine for me in WinCPC until I went to the next room. I've got WinCPC setup as a 464 though.
What was the bug?
Quote from: AMSDOS on 23:54, 17 November 14
It was working fine for me in WinCPC until I went to the next room. I've got WinCPC setup as a 464 though.
What was the bug?
The bug occurs when the code returns from my room-building routine.
I don't know the fix yet - I only know where it happens.
I don't understand why it's happening though. :'(
Quote from: ervin on 00:16, 18 November 14
The bug occurs when the code returns from my room-building routine.
I don't know the fix yet - I only know where it happens.
I don't understand why it's happening though. :'(
Sorry I ask stupid questions :D
I thought that if you eliminate the room-building routine and look at the code for the sprite animation, there maybe a problem there, but if you know where the error is, you know where it's crashing, unless it's crashing because of something else making it crash.
Perhaps something is happening with the Stack, but would of thought Winape would return that as well. So I'm not really sure.
EDIT:I had another play around with it in WinCPC and got this funny result you can see in the screenshot. This is what I got after loading CPC.BAS and specified a lower memory address:
openout"d":memory &2ff
load"cpc.bin",&3700
call &3880
At the top it's got Overflow, followed by Syntax Error and it returned me to BASIC - without Crashing the System. So I don't know if that's anything go to by with what maybe happening.
Hmmm, interesting.
(By the way, thanks for looking into this, I appreciate any help I receive).
I've been working on further narrowing it down.
The crash appears to be in the sprite routine, not the room transition code.
I've put a bunch of PRINTs in, and it appears that memory gets corrupted somewhere in there.
Gonna be tricky to fix...
(Still stumped as to why it works perfectly in WinAPE though!)
SOLVED IT!!! ;D ;D ;D
I now have it working in WinCPC, as well as Arnold on OSX!
I'm soooo chuffed!
I've updated the DSK file in the original post.
For those interested, it was in this little block of code:
di
ld (SAVE_SP_MODE_0+1),sp
exx
ld hl,#1c12
ld de,#1d12
exx
ld bc,#1c1c
push bc
ld hl,_1b+2
ld de,11
ld a,(_spriteWidth)
ld b,a
pop ix
MODE_0_RESET_CODE:
ld sp,hl
push ix
exx
push de
push hl
exx
add hl,de
djnz MODE_0_RESET_CODE
SAVE_SP_MODE_0:
ld sp,#ffff
ei
In that code is a POP IX and a PUSH IX.
It used to be POP AF and PUSH AF.
I can see why it caused a crash - the ADD HL,DE was changing flags and therefore corrupting the AF that I had stored.
However, that worked in WinAPE, which leads me to wonder if WinAPE isn't treating the flags properly in such a case...
Just wondering, is someone able to try the latest version on a real CPC?
I'd love to see a vid of it in action.
I'll get my own CPC out of the cupboard shortly to try it, but in the meantime, it'd be wonderful if one of you excellent folks could let me know if the program now works.
Quote from: Gryzor on 15:46, 17 November 14
@erving , any chance for a scan of those photos? :)
Alrighty, you asked for it!
;D
http://i69.photobucket.com/albums/i57/poppichicken/2854aeec-95eb-41c7-b990-273be2d71ae9.jpg (http://i69.photobucket.com/albums/i57/poppichicken/2854aeec-95eb-41c7-b990-273be2d71ae9.jpg)
http://i69.photobucket.com/albums/i57/poppichicken/88c42b30-689e-481d-b228-f568ea8b277e.jpg (http://i69.photobucket.com/albums/i57/poppichicken/88c42b30-689e-481d-b228-f568ea8b277e.jpg)
Wow... those photos must be 28/29 years old.
Holy cow. Where have the years gone?!?!
Looks like I'm playing Knight Lore in one of the photos (judging by the map), and working on a programming article from ACU in the other.
I'd love to know which issue that programming article is from, but the photo isn't clear enough.
[EDIT] Found it!
I was working on page 66, of the March 1985 issue of ACU (I was typing in Trench Attack)!
It's amazing; to this day I remember typing that one in and running it (and not having any idea how it worked!)... glorious memories.
8)
Hehe, nice pictures!
I think I have some very similar pictures of myself with my Amstrad.
Ah, so this be what you mentioned before with the scaling routines? It's pretty neat and I found the use of Roland on the Ropes sprites very amusing. :)
Quote from: robcfg on 16:11, 18 November 14
Hehe, nice pictures!
I think I have some very similar pictures of myself with my Amstrad.
Yeah, I look a bit different these days!
A bit thinner and quite a bit older! :laugh:
Quote from: Carnivac on 18:08, 18 November 14
Ah, so this be what you mentioned before with the scaling routines? It's pretty neat and I found the use of Roland on the Ropes sprites very amusing. :)
Yep, that's the one! :D
And I can finally say (with these bugs out of the way) that the engine is finally completely finished!
(Well, until the next bug is found).
Content can now be full steam ahead!
Quote from: ervin on 14:41, 18 November 14
In that code is a POP IX and a PUSH IX.
It used to be POP AF and PUSH AF.
I can see why it caused a crash - the ADD HL,DE was changing flags and therefore corrupting the AF that I had stored.
However, that worked in WinAPE, which leads me to wonder if WinAPE isn't treating the flags properly in such a case...
I was reading in my Assembly Book that ADD HL,reg alters the Carry flag, but nothing else. So I'll probably have to check some of my assembly routines which is using ADD that happily runs in Winape.
Quote from: AMSDOS on 09:32, 19 November 14
I was reading in my Assembly Book that ADD HL,reg alters the Carry flag, but nothing else. So I'll probably have to check some of my assembly routines which is using ADD that happily runs in Winape.
Yes, the carry bit being changed in the F register is what was corrupting my code.
Silly mistake on my part.
But the fix is good, I tested this on my 4128plus last night. And it's lovely on the real hardware.
Quote from: CraigsBar on 10:59, 19 November 14
But the fix is good, I tested this on my 4128plus last night. And it's lovely on the real hardware.
Looks like the 4128plus has become your new "standard machine" :)
Bryce.
He'll yes. I love it. I am even thinking of moving the symbiface onto my Amstrad Cpc 6128 and shelving the 2 6128 pluses. The upgraded 464plus is certainly my number 1 Cpc now.
Quote from: CraigsBar on 10:59, 19 November 14
But the fix is good, I tested this on my 4128plus last night. And it's lovely on the real hardware.
Excellent! REALLY glad to hear that it is working on real hardware!
I'd love to get some more testimonials from 464, 664 and of course 6128 users.
8)
I can do that tonight on Cpc 6128 but I don't have Cpc 464 or 664.
The 6128plus will work, it's the same mobo and asic as the 464plus after all.
Quote from: CraigsBar on 12:39, 19 November 14
I can do that tonight on Cpc 6128 but I don't have Cpc 464 or 664.
The 6128plus will work, it's the same mobo and asic as the 464plus after all.
Tremendous, thanks so much for your help.
I would try but I don't think I have the stuff to get a dsk file running on my 464.
Quote from: Carnivac on 15:04, 19 November 14
I would try but I don't think I have the stuff to get a dsk file running on my 464.
No probs, thanks anyway.
:)
Waiting for the next update with some more rooms. :) :) :)
I think walking that way is just great. All this turning around is always confusing me. ;)
Thanks for the photos mate, they really put a smile on my face!
Unfortunately my parents didn't see it fit to take any of me using it back in the day... :(
Quote from: ervin on 10:15, 19 November 14
Yes, the carry bit being changed in the F register is what was corrupting my code.
Silly mistake on my part.
Though interesting it was originally working in Winape, you might have to forward a copy of the original to Richard so he can work out why Winape's not crashing. :D
Quote from: AMSDOS on 09:20, 20 November 14
Though interesting it was originally working in Winape, you might have to forward a copy of the original to Richard so he can work out why Winape's not crashing. :D
Yep, I reckon I might just do that.
8)
Having to ask the author of a software as to why it's NOT crashing? What a strange inversion. :)
Quote from: Carnivac on 12:50, 20 November 14
Having to ask the author of a software as to why it's NOT crashing? What a strange inversion. :)
:laugh:
It's certainly the first time I've ever needed to do that!
If it is indeed a problem with the emulator, it's probably just a small Z80 core inaccuracy.
In any case, it's very easy to work around, and certainly doesn't appear to have been a problem for all these years.
My bet is that the crash is related to the H or the N flag. 'add hl,de' affects C,H and N flags.
The C flag is widely used and an error with that one would have been noticed long ago, but on the contrary H (half-carry) and N (set if the last operation was a substraction), are rarely used, they don't even have dedicated jump instructions.
Moreover, in a discussion I recently had with Syx in a spanish forum he told me precisely about this. He knew for sure that WinAPE doesn't handle the undocumented flags correctly. He told me that it was because it uses directly x86 flags, that are equal for the "standard" ones (C, P/V, Z maybe S...) but not for the others.
Quote from: opqa on 14:17, 20 November 14
My bet is that the crash is related to the H or the N flag. 'add hl,de' affects C,H and N flags.
The C flag is widely used and an error with that one would have been noticed long ago, but on the contrary H (half-carry) and N (set if the last operation was a substraction), are rarely used, they don't even have dedicated jump instructions.
Moreover, in a discussion I recently had with Syx in a spanish forum he told me precisely about this. He knew for sure that WinAPE doesn't handle the undocumented flags correctly. He told me that it was because it uses directly x86 flags, that are equal for the "standard" ones (C, P/V, Z maybe S...) but not for the others.
Interesting... in that case the error is probably with the H flag, as the operation isn't a subtraction.
Quote from: opqa on 14:17, 20 November 14
My bet is that the crash is related to the H or the N flag. 'add hl,de' affects C,H and N flags.
The C flag is widely used and an error with that one would have been noticed long ago, but on the contrary H (half-carry) and N (set if the last operation was a substraction), are rarely used, they don't even have dedicated jump instructions.
Moreover, in a discussion I recently had with Syx in a spanish forum he told me precisely about this. He knew for sure that WinAPE doesn't handle the undocumented flags correctly. He told me that it was because it uses directly x86 flags, that are equal for the "standard" ones (C, P/V, Z maybe S...) but not for the others.
ADD HL,DE will also affect bits 3 and 5 of F, flags so obscure they don't even officially have names!
Quote from: andycadley on 21:31, 20 November 14
ADD HL,DE will also affect bits 3 and 5 of F, flags so obscure they don't even officially have names!
It's most likely one of the obsure flag bits like bit 3 or 5. I will be fixing the flags for the release after next.
Hi everyone.
Time for an update (hopefully they will become more regular in the near future!).
I've been working on my content creation tools over the last fortnight or so, and they are finished!
I now have an Excel spreadsheet whereby I can enter information sign text (game name etc.), sprite sheet configs (e.g. inks), sprite data (e.g. positions in sprite sheet, animation frames), sprite world positions in xyz coordinates, and footstep sounds. I then run VBA code behind the spreadsheet to turn the contents into z80 asm code, which can be compiled, exomised, and written to the DSK file.
This can all happen while the program is running in WinAPE. I run the write-to-disk code in WinAPE's assembler, and then walk out of the room I'm in (in-game, not my actual real-world room!), walk back in, and the changes will load in when the room reloads. It has made a *big* difference to productivity!
I've also fixed a small bug that occurred occasionally with the camera position after viewing an information sign's text (sometimes a minor position adjustment happened, which looked a bit messy).
In addition, there's a new toy to play with. It's a dev tool I've left in the code, that any of you can play around with.
This feature will likely stay in until the final version is ready, hopefully sometime in 2015.
It lets me move a sprite around in the game world, so I can fine-tune the position of each one in real time.
(However, the positions reset when the room is exited and re-entered).
Here's how it works:
(please note that the information sign is not affected by this - it doesn't count as an exhibit).
- press Z or X to cycle through the sprites, as per usual
- this will now display the visible sprite's XYZ coordinates (which has the unfortunate side-effect of slowing the program down, but I can live with that for now)
- the following keys can be pressed to move the sprite around:
- T = up
- Y = down
- U = left
- I = right
- O = away from camera
- P = toward camera
Please note that some values will crash the program (e.g. taking the sprite too high or too low). I haven't built any error checking into the movement code, as it is just intended as a quick and dirty tool to assist with sprite positioning.
I've attached the updated DSK file to the first post in this thread.
Blagger is the game contained in this version, as I wanted to see how many sprites I could to get into a room, and still have a playable frame rate.
(Roland will return soon, I promise!)
I hope you enjoy this new version!
Thanks for this...
And, ooh, just realised the pun with the program's name!
Quote from: Gryzor on 19:21, 17 December 14
And, ooh, just realised the pun with the program's name!
Yes, the name went through many permutations before I found one that was not only a pun, but also made sense in the context of the game. ;D
Also, I've managed to make the program run around 10% faster in the Blagger room!
The speed differences are less noticeable in rooms with less sprites, but rooms with more sprites will now be a bit smoother. 8)
I spent a lot of time researching improved maths routines for the multiplications and divisions required for all the 3D calculations. I was really surprised at the improvements they brought in.
I haven't uploaded this faster version yet, as there is one last optimisation I am keen to try...
Righto, I think I've finished messing about with optimisation. It's about as fast as it's gonna get.
Got a bit sidetracked for a few weeks there... amazing how time flies when you're tearing your hair out trying to make something run a few percent faster!
;D
In order to test the program's speed (now that I'm all out of optimisation ideas) I thought I'd put good old Savage back in.
I've plonked him in the 3rd room, enterable via the door at the back of the Blagger room.
His room isn't totally finished. There is no sound, and I'm not sure if I'll add some animated fire.
I've gotta say, considering how huge he is on-screen, I'm absolutely chuffed with how fast the game runs in Savage's room!
8)
I've attached a new DSK to the first post in this thread, for anyone interested.
(Note that the ability to move sprites around in a room is not present in this version - it is commented out in the code as I didn't want it interfering with frame rate testing).
Wow, that's really looking impressive. Looking forward to seeing what you do with this. :)
Quote from: andycadley on 00:49, 23 December 14
Wow, that's really looking impressive. Looking forward to seeing what you do with this. :)
Thanks Andy. :)
I'm looking forward to having some time to start ploughing content in! ;D
Aaaaand suddenly a few weeks went by!
Development slowed down a bit over the last few weeks, due to Christmas and family holidays.
Back in the saddle now.
8)
A new version has been uploaded to the first post in the thread.
This version contains a couple of new gallery rooms.
I'm finding that the rooms look better and less cluttered when there are less things in them.
That's a good thing as it means content will take less time to produce/rip, and the framerate will also be higher.
It does however make it more difficult to select just what to put in a room!
Also, I've put in a bunch of optimisations; some for speed, but mostly for memory. After some reorganisation, and some hard decisions about sprite sheet sizes, I've got the main .BIN file down to 9.39KB, which I'm pretty chuffed with.
My dev toolchain has also seen a number of tweaks, making compilation, room definitions and map management quite a bit quicker and easier.
Finally, I've decided to leave sound out (at least for now).
If I'm ever going to finish this thing, I need to make some sacrifices, and different (albeit short) walking tunes for each room are taking too long.
I can live with this because it was always meant to be a graphical demo/celebration anyway.
I hope you all enjoy this latest version.
P.S. Look out for the big white bull in the Bruce Lee room. It looks great being scaled in real time!
;D
Great! Now I know what I do at this weekend. :)
Time for another update.
The main .BIN file is now down to 9.00KB.
It won't get any smaller - I don't envisage any more changes to it (unless I get time one day to put sound back in).
Also, the topic is no longer really about Programming, so I've created a new thread in the Games sub-forum, in order to perhaps get a bit more exposure for this project.
I hope that's ok.
8)
The new thread is located at:
Chunky Pixel Curator (http://www.cpcwiki.eu/forum/games/chunk-pixel-curator/)
(Yes, I initially spelled my own game incorrectly in the new thread title, and the thread forever has "chunk" instead of "chunky" in the URL).
:-[
New versions will from now on be uploaded to the first post of that thread.