Chunky Pixel Curator - WIP

[ervin]

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.


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!

[McKlain]

Awesome! It made me smile 

[Morri]

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 ) cracked me up.

[CraigsBar]

Boooo!


It crashes using Arnold on OSX. will have to wait until I get home tomorrow to test it on a real CPC

[Optimus]

Wow! That's another cool way to make a 3d game on CPC. I really liked that!

[ervin]

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]

[TFM]

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

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

[Axelay]

@CraigsBar - 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?

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.

Oh, well I think there's a good chance that's more fancy hardware trickery than a majority of commercial era software. 

[ervin]

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

[CraigsBar]

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

[ervin]

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.

[ervin]

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.

[ervin]

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? 

[ervin]

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

[CraigsBar]

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.

[ervin]

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!

[Gryzor]

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?

[ervin]

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! 
(I've been expecting that exact question, actually).

Yep, I'll upload those photos soon (even though they are rather embarrassing).

[ervin]

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. 

[AMSDOS]

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. 

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?

[ervin]

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.   

[AMSDOS]

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   


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:

Code Select Expand


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.

[ervin]

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

[ervin]

SOLVED IT!!! 

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:

Code Select Expand

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.