Talk:R-Type

• @ Arnoldemu : thx for your comment, it is very interesting indeed...Maybe we should try to improove the actual CPC version by more properly convert the graphics ?

If the code still includes Speccy's colours attributes, it is then probably a waste of memory indeed, as CPC does not work like this. Also if the attribute's Data are Copied (so use twice as memory for nothing) it may be better to properly recode Graphics then in proper Amstrad Mode1 instead of 1 bit code+ attributes.

As the source code is not that bad too, because enemies' pattern and weapon systems are well done, and the mode 1 graphics may be reused too if properly re-coloured (As I did a bit).

Also the source Amstrad Code does include a Raster, to display the red HUD. This may be used betterly with addition of even more colours in said HUD.

Also, does the games use extra memory from a 6128 ? If not, this may give us some room to add stuffs and correct others... And some PLUS features could also be used well in a 128Ko ram version.

So dear ArnoldEmu, if you are willing to share your informations, I am interested, as my friend Fano is looking for a R-type like game project calld Wildfire, and is also currently working on a 6128Plus adaptation/mod of Rick Dangerous. He was looking for how to code R-Type like weapons properly for his Wildfire project, if you analised R-Type codes, this may be usefull for him.

MacDeath-6 nov 2009

• @ MacDeath.

I don't have the time to look furthur, but in my quick look I could see the form of the sprites and the data here in memory and I did some poking to find some simple things.

I started a horizontal shoot em up for cpc a few years back but it was never finished... maybe I should also finish this off now. It is mode 0 standard cpc, standard cpc scrolling. Arnoldemu

• Ok, I understand, thx again.

If you need graphics for such a shmup project, ring me please...MacDeath

fano :

Interesting thoughts.That may be interesting to patch rendering system to draw 2bits chars instead of 1bit.As the game does not use extra RAM, we may store theses char in extra RAM.The code will not have to convert from 1bit to 2bits display so it may be a bit faster.Another problem is to find how scrolling system work.

Other interesting thing would be to look at ST version to rip music and convert to AYC to play ingame w/ madram player without significative impact on game speed :D

The processes used to achieve this result could be used for some other speccy ports.

Why did you stop arnoldemu, i would like to see a schmup from you.

• Concertning Atari ST music Ripp... I though about it too...

After all, it is clever to do Atari ST ports than speccy ports...lol... And Atari ST's music is quite good indeed.

• I stopped because at the time I needed to fix the bullets and firing and I didn't know how to do that best and needed to find a good way to define ememy patterns. I think i can do this ok now. So I plan to re-start the project soon. I've got one other project which is more advanced which I want to finish first. The code is 80% complete.. but some parts may need re-writing I think. The code is about 6 years old.Arnoldemu

Hello guys, since this is a really interesting conversation, why not move it over to the forum (with a link here)? The forum allows for easier communication and it'd get better visibility, too! Gryzor 14:39, 16 November 2009 (UTC)

• thx gryzor , i posted a link on the forum about this discussion.If nobody see problems about , i'd prefer to post technical informations on this page as here it is binded to the game and i don't think it would be very interesting on a public forum.

I started to study the code.The most interesting code to modify appeareance would be at #8A58. Is called from there #86B1 subroutine that is responsible of sprite drawing (#86F3) and scrolling (#8824). The sprites code is weird as there is a different routine for each color.

I didn't finish my attempt to understand the whole code but the main job for this code is to update attributes buffer and uncompress 1bit to 2bit.The code seems to use another table for direct pointers to chars.

The scrolling code (#8824) is interesting too, especially for its usage of the stack to do multiples calls.

Fano 21:49, 17 November 2009 (UTC)

Speccy's fan can laugh about the game speed.A big part of it is a Speccy emulator ! at address #6000 and #6800 are buffer to store characters's pixels , they behave like videoram.I understand now why the game is a bit slow.Each char is copied into theses buffers before rendering.

4 differents routines feed theses buffers (attributes and chars) , 1 for each mirroring type (N = normal , R = reversed) :

• #8D08 - x=N y=N
• #8D70 - x=R y=N
• #8DDE - x=N y=R
• #8E34 - x=R y=R

The bug that delete background near the left border of the screen is caused by star shield routine at #0ED9.

If you want to try to use theses informations, beware in some version some code is not located in the same place.Theses informations have been taken from the Aldo Reset version and the original dump.

Fano 09:58, 19 November 2009 (UTC)

In Nicholas CAMPBELL and CNG versions, code seems to be offseted to -14 bytes.

In original code, the subprogram that load levels is located at #5B64.It gets level number at #719C ,compute track number track=((lvl-#30)*4)+8 and download the 3 tracks (#3600 bytes) at #C4AE so levels are located at track 8,4,12,16,20,24,28 and to finish it calls #8F2A to do loading.

Fano 13:08, 20 November 2009 (UTC)