hello

[Brian Beuken]

yup,
that's why I am curious to see if there is any desire to make a new project...I'm sceptical but lets see.

[tastefulmrship]

Well, I'd be happy to pay real-world monies for a CPC KART game. We had a lot of top-down racers (thanks to the Oliver Twins) but there's nothing in a more Out Run perspective, but in 3D (MarioKart-esque). Now, a lot of people will immediately say "no MODE 7, no 3D kart game" but ervin is currently working on a very fast, chunky 3D engine, so it's not impossbile (just very difficult). Also, with SymbOS networking, we could have network (or online) gaming.

I'd love to play a 3d racer online or networked with other CPC users.

[dthrone]

if I could make 2 or 3K on a project

Look, you'll be duly rewarded in heaven, isn't that enough 

[Targhan]

We have done an adventure game called Orion Prime, and sold it with a real packaging. We consider it a success, as we sold less than 200 units at about 15€ each unit if my memory serves me right.
However, with a "real job" on our sides, it took us 5 years to do it (with a main team of two people, but with several others for the translations of the texts). Ok, it was a huge game, and I'm sure we could have done it in a year and a half, were we dedicated full-time to it. But we wouldn't have made enough money to have a decent living for this year and a half. So to me living from a CPC game development is absolutely not viable. You may prove me wrong, as many people love to buy arcade games.


As for a good dev environment, you can check my article about using Eclipse for Z80 developing. Don't hesitate to ask if that interests you.

[||C|-|E||]

Orion Prime is really amazing... have you ever planned to release a cartridge version? I would be buying it right away.

[Brian Beuken]

Look, you'll be duly rewarded in heaven, isn't that enough 

nope, and I'm an atheist

[McKlain]

I don't think that Orion Prime would fit on a 512KB cartridge.

[||C|-|E||]

You are right... it would not fit in a standard cartridge at all 

[Targhan]

No, Orion Prime would not fit in a cartridge, sorry .

[Joseman]

talking about orion prime... is the source code available?

I miss so much symbiface 2 mouse support and HDD compatible...

[||C|-|E||]

I definitely plan to play it in the plus, but I will wait to have the HXC and a mouse to enjoy it properly. It deserves it  .

[Targhan]

No, the source code is not available. I don't really want to do the maintenance of it...


@[[C|-|E]] : no mouse support on Orion Prime!

[||C|-|E||]

Ups! I saw the pointer and I assumed that it would be possible 

OK, I will play it anyway! 

[TFM]

nope, and I'm an atheist

So you can't blame god for it?    Oh well, there is a Z80 heaven for all of us. 

[Gryzor]

A bit late, but: welcome mate, thanks for joining the community!!

[Brian Beuken]

Curious to see where this might take me

I really used to love the CPC back in the day,  I will certainly try to score a development set up and have a noodle about with it. I'm kinda hoping there is some momentum to get a game written again.

[arnoldemu]

Welcome!

[arnoldemu]

Brian, I have a few questions which I would appreciate if you would answer

1. You mention Rockford 2. I don't see this on CPC-POWER, sauvegarde du patrimoine de l'Amstrad CPC . Was it released for CPC?

2. With DJ Puff's Volcantic Erruption I see that the "Rupture" demo technique is used. This technique uses CRTC's register 4 (vertical total) and CRTC's register 7 (vertical sync position) to split the screen into multiple sections allowing R12 and R13 (start address) to be re-loaded and allows, for example, hardware scrolling at the top and a static status panel at the bottom. How did you find out about this technique and how did you cope with the compatibility of various CRTC types (HD6845, UM6845, UM6845R and MC6845)?

I think this technique was also used on Rockford and Rastan. (Mission Genocide uses it really well giving very smooth pixel by pixel vertical scrolling using CRTC register R5).

It's interesting for me because very few games used it. It often involves precise timing, but it allows good flexibility and the ability to scroll the screen vertically pixel by pixel in combination with hardware scrolling. Horizontally, R3 can be used for smoother movement.

3. How did you find CPC's hardware scrolling?

Not many games use it. If you scroll a lot you also need to cope with the wrap around address, meaning sprite drawing can be slower, and often many games don't use it well and makes things worse (here I talk about ghosts and goblins where the scrolling is hardware based, but a small bit at a time - could be improved with some tweaking I believe).

I am really interested in your view.

[Brian Beuken]

Brian, I have a few questions which I would appreciate if you would answer

1. You mention Rockford 2. I don't see this on CPC-POWER, sauvegarde du patrimoine de l'Amstrad CPC . Was it released for CPC?

2. With DJ Puff's Volcantic Erruption I see that the "Rupture" demo technique is used. This technique uses CRTC's register 4 (vertical total) and CRTC's register 7 (vertical sync position) to split the screen into multiple sections allowing R12 and R13 (start address) to be re-loaded and allows, for example, hardware scrolling at the top and a static status panel at the bottom. How did you find out about this technique and how did you cope with the compatibility of various CRTC types (HD6845, UM6845, UM6845R and MC6845)?

I think this technique was also used on Rockford and Rastan. (Mission Genocide uses it really well giving very smooth pixel by pixel vertical scrolling using CRTC register R5).

It's interesting for me because very few games used it. It often involves precise timing, but it allows good flexibility and the ability to scroll the screen vertically pixel by pixel in combination with hardware scrolling. Horizontally, R3 can be used for smoother movement.

3. How did you find CPC's hardware scrolling?

Not many games use it. If you scroll a lot you also need to cope with the wrap around address, meaning sprite drawing can be slower, and often many games don't use it well and makes things worse (here I talk about ghosts and goblins where the scrolling is hardware based, but a small bit at a time - could be improved with some tweaking I believe).

I am really interested in your view.

1. as far as I know it was released...Rockford was intended to be 1 game, but due to the amount of levels and graphics for those levels it made the overall size of the data very large, a decision was made to split it into 2 separate versions. Exactly the same code but new maps and graphics.. I honestly don't recall if it was released. But I do remember the decision and making 2 masters. I think there were 5 in each???

2 Ah that's a good question, it was actually a colleague, we nicknamed Orange Prof, I sadly don't recall his real name, he was very technically minded, (another colleague Paul Windett was nicknamed Prof due to his wild hair and beard hiding his eccentric intellect, and Orange Prof also had a wild bearded appearance but he was a redhead), anyway it was he  who noted that it was possible to generate 2 or more vsyncs, and using interrupts which occurred at fixed points on the screen refresh cycle, we could time the Vsync and changes of the mode and screen offsets. It took a bit of experimentations since the new syncs also altered the timing of the interrupts, but we managed to produce a stable split and resetting the screen to a non scrolling base. This in theory allowed us to have a much more stable scrolling screen with a fixed panel as you point out, using the screen registers to let me do a dregree of hardware scrolling and then updating only the edges/sprite damaged areas for faster updates.

I think I did it 1st on Rastan, though it might have been Rockford, I can't remember...but I do recall there was a problem with we sent a demo down to Ocean of a 1st level play through of Rastan, they called us up and were angry that the game was rolling on the screen... This was a mystery to us. So myself and a manager went down to Oceans Central Street office to see for ourselves, sure enough it was rolling, or not syncing properly...

It turned out that not all CRC devices were synced quite the same, there was a screwdriver hole in the back you could adjust to ensure the timing was correct, but Ocean were far from happy with that solution, I think someone quipped, we can't supply a screwdriver with every copy.. But it was basically a hardware issue we could not resolve in software, so they accepted that the majority of devices would be fine, and would offer a customer who had problems the info on how to adjust or give a refund. I never heard of any issues with Rockford or DJ Puff, I don't know why only Ocean's test machines seemed to consistently show a problem.

3 it was ok, it meant I didn't have to dump a whole screen of pixels, only the edges and the area where a sprite was moving... But that could actually be slower to calculate than dumping the whole screen, it would depend on the game, and you had to keep track of the offset which in turn made the sprite draws much slower...you often gained one thing but paid for it with another. It also had the benefit of freeing up some of the screen RAM if you were careful, you could avoid the double buffer on the panel, and make use of the back buffer panel area as extra volatile storage. I think that happened in Rastan, every single byte was used and I spent several weeks trying to squeeze more and more in...it was genuinely a nightmare trying to get it all in.

Hope that answers things...my memory of those days is a little foggy but its nice to recall some of the people and events that shaped me.

[Gryzor]

Thanks man, so nice to have an old coder answering questions...

[arnoldemu]

Thankyou

Very interesting

I'll check Rastan, it probably needs a slight timing fix.

The rolling may be down to the frame that was generated being less than or greater than 312 scanlines. Some monitors are tolerant, and depending on vhold, will latch onto it and make a stable display. I'm guessing the code has less lines output.

EDIT: Confirmed, timing is not good Concerning Rastan, you had 42 char lines per screen giving 336 lines per screen; making the frame a bit less than 1/50th for a frame. So the screen would roll.

I modified it here with the following pokes:

2fba=&10
301e=&10 (17-1)
306e=&15 (22-1)

22+17 = 39 char lines, 8 lines per char -> 312 lines

now you have 312 lines per screen, each frame takes 1/50th of a second and should not have any rolling. I would need to check it on real hardware to know if it's a good fix or not.

EDIT2: Rockman has 37 char lines per frame, so is a bit short. The screen should roll with this, but it may just be in tolerance. I've not found the appropiate pokes yet. I can make a stable display but the mode change is wrong because of the altered interrupt timing.  I'll take a look tomorrow on how to fix this.

I think almost all games that use rupture have incorrect frame timing. I think because it wasn't so understood as it is now. So I believe you were not alone. Some games such as Octoplex only work on one CRTC type because the register writes are responded to in a different way between CRTC types.

It is a shame, more games could have benefitted from this method. We would probably have a lot more vertical scrolling games and CPC would have much less of a bad reputation concerning scrolling.

[Brian Beuken]

yea it was try it and see method of coding we didn't really know the maths then, we just tried twiddling different numbers till we got it right... I'm pleased to know there is a way to actually work it out...

[TFM]

Yepp, the pioneer years. The CPC was still a mystery and it was lots of fun to find out new possibilities. Maybe even today it hides one or two secrets. 

[Executioner]

I was thinking of writing a game that uses more than 312 scan lines per frame just so I can fit all the stuff I want to do in one (slightly larger) frame, not sure what most monitors will tolerate though!

[TFM]

For Giana Sisters I use 288 scanlines to display the picture. I assume that not more than 294 can be seen on a regular color monitor (only 272 on a green monitor!). Hope that helps.