View source for 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! [[User:Gryzor|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.

[[User:Fano|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.

[[User:Fano|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,12,16,20,24,28,32 and to finish it calls #8F2A to do loading.

[[User:Fano|Fano]] 13:08, 20 November 2009 (UTC)

== Objets/Sprites subsytem ==

The routines used to put sprites/objects to the rendering system (#8D08,#8D70,#8DDE,#8E34) take the following parameters :
*HL sprite graphics address
*D,E sprite dimension in char units (height,width)
*B,C sprite position in char units (y,x)

Sprite graphics are composed of theses structures:
*BYTE : attribute
*BYTE*8 : 1bit graphics , only present if attribute <> #36

Attribute seems to be only used to compute color, only the 2 lower bits are used like this :
* 10 (2) : color 1
* 11 (3) : color 3
* 00 (0) or 01 (1) : color 2

There are 2 routines to solve sprite dimensions and adress from a sprite number in A : #8E97 for basic sprites (héro,modules,weapons,logo,etc...) and #8E90 for levels sprites.Theses routines return pixels address in HL and dimensions in char units in D,E.

Sprites tables are composed of theses structures :
*BYTE width in char units
*BYTE height in char units
*WORD pixels address

The basic sprites table if located at #BC67 and level sprites table address can be found at (#C4BA)

Here is some example code written in Basic to convert R-Type sprites from uncompressed 64K type 1 SNA to BMP format :[[file:R_extractspr.x]] 

Example : 
[[File:Spr_40.png‎]]

(Violet chars are marked as #36 so they are ignored)

[[User:Fano|Fano]] 16:47, 21 November 2009 (UTC)

==Level graphics==

Let's continue for 2K10 !

Game screen is composed of 8*5 blocks of 4*4 chars (8*8 pixies).Blocks are stored in memory in the same way as sprites except char pixies are always presents.

Per char :

*BYTE : flags, defines color, bit 7 defines if char is solid.
*BYTE*8 : 1bit graphics

There are 16 chars so 144 bytes per block.

Levels are composed of columns of 5 blocks.The first column of the level is located at #C4B1 (byte).The column number 0 is located at (#C4BC)

A column address (word) can be computed like this : (column*5) + (#C4BC)

Each byte of the column is a block number :
* bit 7 -> set if verticaly reversed
* bit 6 -> set if horizontaly reversed
* bits 0->5 block index

Using block index , it is possible to compute address (word) with this simple formula : 

(#C4BC)-((index+1)*144) 

Routine at #167B solves block index in A and return block address in HL.

Code located at #5C4F draws the first screen of the level before scrolling.It uses the sprite code (#8D08,#8D70,#8DDE,#8E34) to put the level graphics on screen.

Current column is located at #7A84 and there is a copy of (#C4BC) at #C4AE.When game passes a checkpoint , it saves the current column at #C4AE so when player dies, game restarts at #C4AE.

Code located at #8A7F feeds scrolling , update attribute array , draw blocks on right side of the screen.There are 4 routines to feed scroll according to reverse flags.

* #1E4C - x=N y=N
* #1E83 - x=R y=N
* #1EC3 - x=N y=R
* #1640 - x=R y=R

[[User:Fano|Fano]] 20:23, 6 January 2010 (UTC)