R-Type

[TotO]

The programmer made a choice to make it this way.
I have some games in development. they will run in 64k. but use 128k for extra stuff!

Because it was possible, you make the good choice.

I also have a plus machine. Why did you not make it so it used plus extra features? Why, because you chose to make it for CPC.

Because Plus features can't be combinated with Old one. So, we take the choice to make it compatible for most CPC.
The first R-Type mock-up use Plus palette...

- 6128 / 6128 Plus (KB map 1)
- 664 + EXT RAM (KB map 2)
- 464 + EXT RAM + EXT Floppy (KB map 2)

We can't do it 64K+64K. But if it had been possible, we make it with optional features too.

[SyX]

Maybe I am ignorant, but where can I find memory for the 464 that can be easily fitted?

Well, Bryce is working in a nice ram expansion for all the CPCs, because that it will not be a problem very soon

[TFM]

 
Now I want to bother all of you with my opinion...


If a programmer decides to make a game in a certain way, then it's the programmers decision, and nobody elses. Nobody has the right to quesion that. Anybody who questions it, is just respectless.


If one doesn't like the way a programmer made his game, then this person doesn't have to buy (or use) it!


Oh, and if you haven't paid any money, then please do this: 


I'm really not a person who values money (too) important. But in general it suxx if people use non-constructive sharp critics for a free "product".

Constructive critics is for sure always welcome to the very most programmers though.

[TotO]

If a programmer decides to make a game in a certain way, then it's the programmers decision, and nobody elses.

The discussion is about the usage of the extended memory.
BB4CPC, R-Type and Amiga games are just examples for that.

Nobody has the right to question that. Anybody who questions it, is just respectless.

Sure, programmer is god, you musn't pronounce his name. 

OFF TOPIC. BACK TO R-TYPE NOW.

[fano]

Say my name ! say my name baby !

To close the topic about 64K version , i share a document of the project about the global memory map (ingame) , that will be difficult to fit in 64K 

[HAL6128]

Wow! Thanks (from my side) for sharing this interesting insight.
This means that only 19 kB is program code and the rest are datas for graphics, sound, tables and temporary storage?!

[fano]

Happy to share this and to find someone interested 
Yes and No as there is code for enemies and level logic (some levels like 3,4,5 own a very specific logic) at #9000 and the whole sound code (with decompressor) has been exported in sound module.
The menus callbacks are loaded in bank #C4 in main screen too.

[TFM]

Actually it's really amazing that you do it with only one screen RAM - without flickering or any other disturbing effects.

You guys get my personal 100.000% Vote 


BTW: BB4CPC is a quite wonderful game, only the sprite flickering at the beginning really confuses me a bit. But hey it's a feature, not a bug. And for 64 KB it's really amazing too.

[ivarf]

So why do the sprites in new Bubble Bobble flicker and what has it to do with 64 kB memory? Something to do with waiting for the frame flyback or whatever it is called - bb19 I think?

[fano]

Problem is the Z80 is too slow refresh screen and draw sprites so the job is not finished when electron beam comes , that causes flickering or tearing.
The most common (easy?) solution is to use integral double buffer but it needs 2 screens so 32K for a standard screen format and only 32K remain for the game itself.

[arnoldemu]

So why do the sprites in new Bubble Bobble flicker and what has it to do with 64 kB memory? Something to do with waiting for the frame flyback or whatever it is called - bb19 I think?

flickering sprites has nothing to do with the amount of ram.
the sprites are more likely to flicker if the display is not double buffered.
I have written some test programs which I will publish this year with my investigation into flicker free sprites without double buffering.

[TFM]

flickering sprites has nothing to do with the amount of ram.

Well, I assumed the RAM was used up, so there is only very few space for a "crappy" sprite routine.

the sprites are more likely to flicker if the display is not double buffered.

Well, using quick routines you don't need double buffering for that. Just start do undraw/redraw the sprites as soon as the scan-line is right below them. And you can use all six interrupts to kick the sprite routine. Ok, let's calculate.

Due to the precision of six interrupts per second we lose (in maximum) 1/6 of 20.000 ys (one frame roughly, ok it's 19xxx, but I calcualte in mind here ;-) ). So we have left: about 16600 ys.

There is (IIRC) no background. Also we need no "undraw" since sprite don't jump, they just slowly move. So we can use routines which (if still usable in general) can move a byte in about 6 ys. So we can move about 2700 bytes per frame (without any superquick sprite routines in use).

This would be about 54 pixel (in X) * 100 pixel (in y). So roughly 1/6 of the screen.

That's all calculated very rough. But it shows it is not a problem to do it flicker-free in each frame (no buffering).


EDIT: For my upcoming game Cyber-Huhn I'm using Sprite routines which need  between 3 ys and 4 ys per byte. But this may be already close to the upper limit of speeding up sprites.

Link here:

huhn2.avi

[arnoldemu]

Well, I assumed the RAM was used up, so there is only very few space for a "crappy" sprite routine.

I was being a bit of an idiot and I over re-acted to the 64k vs 128k debate.
I thought they meant that 64k games have flicker, because they are 64k games and 128k games never have it.

Well you are correct there was probably not much space for sprite routine and not much cpu time also for it.

Your description of flicker free sprites is good, and it seems that jet set willy may use this.

So of course, to do this, you need to "sort" your sprites in y, whether you do this with a true sort routine, or if you know already the y position and can hard code it.
Then you have some way to wait until you are safe to draw.

[ivarf]

Well, I assumed the RAM was used up, so there is only very few space for a "crappy" sprite routine.
 
Well, using quick routines you don't need double buffering for that. Just start do undraw/redraw the sprites as soon as the scan-line is right below them. And you can use all six interrupts to kick the sprite routine. Ok, let's calculate.

* explaination removed *

This made me think about coding for the Atari VCS

[TFM]

So of course, to do this, you need to "sort" your sprites in y, whether you do this with a true sort routine, or if you know already the y position and can hard code it.
Then you have some way to wait until you are safe to draw.

Of course, you're right. And the more sprites you have the more "complex" it may get. (Especially when you have all that other stuff: colission dedection, different phases which which can affect shape and therewith x,y; and and and...)

This made me think about coding for the Atari VCS

Bolt Man!

[MacDeath]

huhn2.avi

looks like a promising Wing Commander clone on CPC...

I was being a bit of an idiot and I over re-acted to the 64k vs 128k debate.

the problem is not that you can't do great games with only 64k...
It's that you can't do big games... big like... as on 16bits...


=Atari ST : 32K VRAM... 512K RAM
you can "store" 16 full screen of pure Graphics datas, sort of.

=Amstrad CPC : 16K VRAM....64K RAM...
you can only store 4 screen of pure Graphic datas... sort of.

64K were perfect for old school games like Jet Set Willy...
But look at rick dangerous : half the levels, half the sprites and slow downs...

but if you want many sprites frames, lots of tiles, or pre scaled "zooms", many cinematic effects... this won't cut it.
Or even simply a deep gameplay with lots of fancy stuff, or bigger levels.

and I only talked about pure graphics...
Having more RAM enable many "lazy" technics to have a faster and smoother thing... just because you are more prone to have one free 16K additionnal RAM bank to do some double buffering.


To be fair, 64K can be good provided you use disks... (they are quite fast and can search for more datas more often than tapes) yet some DMA for the diskdrive wouldn't hurt...

but if you were a avid Tape user, you should know about those games where you waited 15-25minutes to load the second level, then loose your last life and had to reload the first level to restart the game...

thats mostly why many Dinamic/spanish games had multipart games with code to play then independently... but also why they often had drastically reduced screen...

to be a full power, the 6128 configuration is where its at.

look at games like midnight resistance or Gryzor...
the guy is supposed to fire in 8 directions... he can duck and jump too... and has to wlak/be animated realistically...
Having shittons or RAM enable to have all those sprites in store, with no CPU intense mirror effect, nor the need to uncompress Datas while running the game.

but there is also the cartridge solution (ROM based game...) which then leave enough RAM to do what you want ads you don't have to store abny "sleeping datas" in it.

[TFM]

In extreme: Cart based games can use the 64 KB RAM "just" for screen RAM and variable memory ;-)

[Gryzor]

Well, after finally reading the review a couple of nights ago... I don't get it. Despite the crashing bug, I don't see how Jar's Revenge on the c64 ("beefed up graphics"? ) would get 88% vs R-Type's 82%, and then you have this:
[attachimg=1]


...which gets a 84%? Aw, come one. It may be a nice game, but it's so simple and primitive... I call shenanigans.

[fano]

But... ...do theses games own keyboard redefinition ? 

[TMR]

Aw, come one. It may be a nice game, but it's so simple and primitive... I call shenanigans.

i'm sorry you don't agree and feel a serious, show-stopping lock the machine up and blackscreen bug is trivial enough to ignore when scoring a game, but i'm afraid i don't. They don't, but had Prince of Persia on the C64, More Tea, Vicar? for the Spectrum or Space Harrier on the Atari 8-bit crashed as badly and frequently as i experienced R-Type doing i'd have marked them down as well so please don't imply it's anti-CPC bias on my part.

[Gryzor]

Whoa; I'm not implying anything. What I said was that, personally, I was ok with the 82% -not happy- although it did sound a bit on the low side. But when I saw the other games, being such as they are, getting higher scores, then I felt it doesn't add up. I mean, heck, take the bug away, and compared to those other two titles what should R-Type get? 110%? I feel the scale is off.


I do know how hard it is to rate games. Heck, it's been discussed so many times in the past it's boring to even mention it. I also understand that you can't rate a game based on a few strict, technical factors solely. That said, it feels disapointing that a title that took a tremendous effort, proved lots of things and made us all proud (and, oh, is a tremendous game to boot) should get an oh-kay rating. It doesn't make much sense.


And again: I did not imply anything at all.

[TFM]

... so please don't imply it's anti-CPC bias on my part.

Hahaha, yes sure! And Earth is a flat disc!

[TotO]

Please, stop...
He got a fixed version and can make a better test, now.

[beaker]

....i'd have marked them down as well...

First off I'll get the brown nosing out of the way... I've been reading RG for 2 or 3 years now and into my second subscription (before that I was just buying the odd copy), and RG is the main reason I took another look at the old machines and decided to buy an Amstrad again, as well as a load of other kit... and I enjoy reading your Homebrew section.

Going on from what Gryzor was talking about earlier, and not wanting to offend in any way, but part of the confusion (for me) is how you arrive at the scores; how do you (and possibly the Retro Gamer team) score the games? Is it a case of breaking the game down into sections such as graphics, sound and gameplay, weighting them and then calculating a score? This also applies to the retrorated section where I just see a score at the end of the article.

Given the Homebrew section is getting a few extra pages from issue 104 (according to the link below),  would it be possible to break down the scores to make them more transparent?

Retro Gamer Homebrew Changes

[TMR]

Whoa; I'm not implying anything.

Shenanigans means "a mischievous or deceitful trick, practice, etc." and i read that as an implication - you probably caught me at a bad time, but that's no excuse and i shouldn't have snapped so i apologise.

What I said was that, personally, I was ok with the 82% -not happy- although it did sound a bit on the low side. But when I saw the other games, being such as they are, getting higher scores, then I felt it doesn't add up. I mean, heck, take the bug away, and compared to those other two titles what should R-Type get? 110%? I feel the scale is off.

My "system" (and it really is mine, i've never received guidelines from Retro Gamer) is somewhat "top heavy" and my editor assumes it's down to my enthusiasm for homebrew and he's probably right to some degree. But by my reckoning, an average game scores somewhere in the 60s, a good game in the 70s, a great game in the 80s and something exceptional (like R-Type) in the 90s. But as a programmer myself, i reserve some of those percentage points to technical issues (i think i've said about 20% in the past but it's honestly nowhere near that scientific) so if a game has glitches or minor hiccups it'll lose some points and a serious show-stopping crash will lose significantly more from that reserved range.

i'd much rather have a scale of 1 to 10 really because there's always an assumption with percentage scores that there's a mathematical process behind them (i know one review site that used to do that and it really skews things if something like the music's a bit crap on an otherwise excellent game) but i've asked for it on numerous occasions with no joy...