Difference between revisions of "Talk:R-Type"

From CPCWiki - THE Amstrad CPC encyclopedia!
Jump to: navigation, search
Line 23: Line 23:
 
*Ok, I understand, thx again.
 
*Ok, I understand, thx again.
 
If you need graphics for such a shmup project, ring me please...[[MacDeath]]
 
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.
 
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.
 
Why did you stop arnoldemu, i would like to see a schmup from you.

Revision as of 04:54, 14 November 2009

  • @ 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.