R-Type remake!

[Gryzor]

Hey, I just heard that some crazy guy is not content with the original release's quality and is doing a remake with better gfx and music and all that. Hope it turns out good, I'm going to play the first beta now!
http://dhs.nu/news.php?t=single&ID=829


(heh, got you confused there for a sec, didn't I?)

[TotO]

Hey!

R-Type was a shame on ST, so it's nice to do a remake on STe.

The chance is to be able to work with the real arcade GFx as the STe offer the same 12bit color space on 1:1 pixel ratio.
The Blitter will help a lot, the only problem will remain on the 16 colors palette management. (arcade have 32x 16 colors palettes)
Is possible to get a 320x224 screen (at less) on this computer?  (arcade is 384x256)
I would killed for a 16 colors Mode 1 on CPC!!! 

About sound, I hope they will be able to handle a good 4 channels music port + sfx, to be close to the original arcade tracks.
Please, do it "arcade spirit", never look at the existing Amiga/C64 poor ingame ports or something else.

No screenshot available? (I can't run the STe emulator)

Good luck to us!

[Sykobee (Briggsy)]

Nice to see other platforms get some love, especially the enhanced ST as very little actually made good use of its hardware.


I don't know if the ST had programmable displays like the Amiga, or even the MC6845, everything I read about it said it was a fixed 320x200/640x200/640x400 display.


A 16 colour MODE 1 on the CPC would have left hardly any RAM for the graphics and game, never mind the poor CPU having to manipulate it all! Even on a 6128 it would have been a squeeze. However an attribute mode that allowed for, e.g., four 4-colour palettes to be used on a standard MODE 1 screen to get up to 16 colours would have been nice to have, (for this example, it would have used an additional 200 bytes of RAM (2 bits per on-screen character block)). Maybe an FPGA CPC implementation could add one for a laugh via some "attribute RAM" much like the "sprite RAM" in the Plus.


And yeah, I find retro game posts that link to an executable to be quite annoying - show us a screenshot, or a video. Some of us are browsing at work, or don't have the necessary emulator to hand.

[TotO]

However an attribute mode that allowed for, e.g., four 4-colour palettes to be used on a standard MODE 1 screen to get up to 16 colours would have been nice to have

Sure, it would have been a nice alternative.

[arnoldemu]

The ST screen is 320x200 in lo-res. To make overscan takes a lot of CPU cycles.

You can do a 50hz/60hz switch in the lower border to open it up. That's the easiest. To open the top border you have to do a 50hz/60hz switch at the correct time and that opens it up. When I say opens the lower and upper border, I mean excluding the left/right sides, the border is opened to the width of the normal screen I think.

To open the left/right borders you have to do a 50/60hz switch at exactly the correct cycle on *every* line. I don't remember if you do the switch on the right side to open both right and left, or you must do it in 2 places, once for left and once for right.

So those overscan demos are really impressive! Because they must count cycles like we do on cpc.

The screen can't be made smaller.

If you want to simulate that clip the sprites on the right/left sides.

The ST can do a form of hardware scrolling called "sync" scroll. on normal st, it's limited to 16 pixels at a time, ste has a "soft scroll" register like the cpc.

So you need 16 copies of the screen to do 1 pixel scroll on normal st.

In addition because the screen doesn't wrap like on the cpc, you need to have 2x the screen in height for vertical scroll, draw the same row above and below, and adjust the screen address to do the wrap at the correct place. For left/right you need 2x the width I believe.

So hardware scrolling on the ST can be done and takes loads of ram.

it's easier on the ste with it's soft scroll register, but you still need plenty of ram.

A software scroll is possible, but again, like on cpc, it takes lots of cpu time.

The blitter on the ste, is not as good as the amiga's but it will help. Best to use it in "hog" mode where it takes the cycles from the cpu when it does it's work, but it can run faster.

(Amiga's display also didn't wrap, but you could write a copper list that changed the screen address and split the screen into 2 horizontal blocks of varying heights depending on the scroll, but it did have the soft scroll hardware.)

It will be interesting to see r-type working on ste. certainly possible.

[Gryzor]

Here's some screenies for grumpy Briggsy who seems to think I made the original article


[attachimg=1] [attachimg=2]


[attachimg=3] [attachimg=4]


[attachimg=5] [attachimg=6]


[attachimg=7] [attachimg=8]


[attachimg=8] [attachimg=9]


[attachimg=10]


It really is a beaut, ain't it? Notice that there's only one type of enemy right now, the boss doesn't do anything and other elements are missing too.

[TotO]

Thanks!


The GFx look good. Better than the existing one. (but not arcade, ST redone)
The title screen come from a R-Type Delta artwork.

[Gryzor]

The rendering of the loading screen is exceptional. Someone count the colours in it

[Sykobee (Briggsy)]

Looks pretty tasty to me! And yes, there appears to be just a few more colours than the normal ST palette size in that title image - some form of ST-esque MODE 5 at work?

[SyX]

Looks pretty tasty to me! And yes, there appears to be just a few more colours than the normal ST palette size in that title image - some form of ST-esque MODE 5 at work?

Of course, nice timer interrupts, for making the rasters and having free cpu time

[Sykobee (Briggsy)]

I expect the palette changes can be done quite finely with an 8MHz 68000 rather than a 4MHz Z80.

[TotO]

The STe allow to r/w the video address counter... May be more easy to use INT to change the colors palette with that.
In all case, it was nice done.

[arnoldemu]

The STe allow to r/w the video address counter... May be more easy to use INT to change the colors palette with that.
In all case, it was nice done.

ste has 4096 colours, so it may be that, and "spectrum 512" like mode.

[MacDeath]

I really like the STe... quite like the PLUS, this machine didn't get the love it deserved...


Of course some may argue the A500 is still better... perhaps.
But the STe is what the STF should have been from the begining.
Amiga could of course deal with 5bpp graphics (=32 inks) and its Hardsprties are also quite good...
But as the Atari STe is in only 4bpp, it is lighter (provided the Amiga doesn't also use a 16 inks mode) and the blitter is still helping a lot more than on the STF (= fully software).
As a result, not sure it can't be as smooth as on an Amiga or even a console (like the SegaMD or the PCengine), as the CPU on the ST is also slightly faster than on the Amiga500.

It can quite easily pack a good load of RAM, and have "normal" 720K floppies so is quite easier to get runing now.

The video modes are simple, sort of like Amstrad CPC in 16bit... still quite exploitable.
A clever pixelisation and pixel art job plus a few raster effects can really be more than enough to have a nice graphics set.

320x200x16/4096 is clearly quite enough to have a decent looking R-Type.
Perhaps a double buffered game could actually do some flickerscreen effect to add a few colours... would need to double the tile/sprite sets and to change the palette between each displayed screen, would also need to keep a few inks the same in both flickers so it would be less epileptic.
lets says to have something like 4-6 inks flickering could really be nice enough, but again, I don't know if this could be possible nor easy...(a 1040 configuration and to reload Datas for each level could be helpfull too...).

To get smoothscrollings and blitter assisted soft sprites is also clearly a nice addition.

I could never find information wether those "sprites" can get additional colours the way the amstrad PLUS does or if the blitter simply ease the masking process yet the colours remain limited to 16 per screen/scanline...

Despite all this, having better/easier scrollings and masks for sprites surely let a few extra CPU to get huge loads of Raster colour changes... don't know how well the STe can handle split rasters though.

I think ST/STe are quite limited to a straight 320x200 resolution (or doubled 640x200x4 or even 640x400x2 in monocolour special monitor (which I do have)
The CPC's ability to get a whole overscan "384x272" resolution (or the same but magnified in Mode0 and mode2) was actually quite rare on most computers.
The Arcade may use such an "overscan resolution with shitons of multiple palette (attribute like display, extra palettes for sprites too), still a 320x200x16 may be enough... not Arcade perfect but still good enough, provided a few Demo tricks are used.

(After all, Toto, you had not that much more than this for the CPC6128 deluxe Easter eggs edition)

R-Type was said to be shitty on the ST... I played it and found it decent... I mean I was used to the CPC's speccy port to begin with.
But of course a true STe version could really be nicer... the extra sample sound channels can really give a real plus to the existing YM (= AY clone) and be quite helpfull to deal with nice sound FX in addition to music (having a 1040 config may help too).
Can't wait to see the final release, I hope they will include as many option as Easter Egg version did on the CPC6128.

The rendering of the loading screen is exceptional. Someone count the colours in it

A static picture can get a full array of raster effects so the 16 inks limitation does mean nothing here...
When dealing with animation, sprites, scrollings and a whole game engine, this is a different matter of course...

Now I hope someone will do a proper STe BlackTiger/Dragon version...
Pacmania could be nice too.

[MacDeath]

sorry for the double post...


discussion on the R-Type sounds :
http://www.atari-forum.com/viewtopic.php?f=3&t=22924


discussion on the R-Type artworks :
http://www.atari-forum.com/viewtopic.php?f=3&t=22918

[TotO]

I sugget that this people take a look on the Arcade version, as all this demo look to be a recolored ST one.

The STe AY and it's DMA stereo DAC can allow to have a really nice ingame sound w/o wasting CPU time.
3ch AY for main music instruments + PCM for digidrum music instruments and effects... It's possible to transpose the original 4ch music and play great SFx over it.

[Sykobee (Briggsy)]

I really like the STe... quite like the PLUS, this machine didn't get the love it deserved...


Of course some may argue the A500 is still better... perhaps.

The Amiga is streets ahead of the ST[F[M]], and the STE catches up somewhat.

But the STe is what the STF should have been from the begining. Amiga could of course deal with 5bpp graphics (=32 inks) and its Hardsprties are also quite good...

The Amiga also had a 64 colour mode, dual-8-colour playfields, or 4096 colour HAM mode. And a very featureful blitter. And let's not mention the audio! Nor the copper co-processor.

But as the Atari STe is in only 4bpp, it is lighter (provided the Amiga doesn't also use a 16 inks mode) and the blitter is still helping a lot more than on the STF (= fully software).
As a result, not sure it can't be as smooth as on an Amiga or even a console (like the SegaMD or the PCengine), as the CPU on the ST is also slightly faster than on the Amiga500.

The Amiga could have any number of bitplanes from 1 to 6 (8 on AGA machines), i.e., 2, 4, 8, 16, 32 or 64 colours on screen at any one time.

The video modes are simple, sort of like Amstrad CPC in 16bit... still quite exploitable.
A clever pixelisation and pixel art job plus a few raster effects can really be more than enough to have a nice graphics set.

Indeed the ST is very much a 68000-based CPC in spirit. The CPU ends up doing all the work :-)

I could never find information wether those "sprites" can get additional colours the way the amstrad PLUS does or if the blitter simply ease the masking process yet the colours remain limited to 16 per screen/scanline...

Blitters aid in memory copying, and merging from multiple memory sources (e.g.: (graphics data AND mask data*) OR (screen memory AND NOT mask data) -> screen memory) - never a fun thing to program, that.


* mask data could be a specified colour number

Despite all this, having better/easier scrollings and masks for sprites surely let a few extra CPU to get huge loads of Raster colour changes... don't know how well the STe can handle split rasters though.

The ST could change the entire colour palette three times per scanline - this was used in the Spectrum 512 graphics application for example. I doubt that many games used this however - maybe for background gradients and the like.

[MacDeath]

This thread becomes an Atari ST(e) thread I guess...

I found some documentations on the STe.

Atari STE fanpage
Atari STE fanpage

Seems like one of the problems with the ST range was that there was too many specifications that most of time failed to emulate properly the past upgrades but could have less problems with the basic original ST config (as it has nothing additionnal...)

First the range was split between the "STs" (STF/STFM/ST, STE, Falcon, combined casing...) and pro-version "Mega STs" (desktop with separated keyboards, MegaST, MEga STE, TT...).

Most of time the Pro version were a crossbreed between 2 generations of basic STs...

The blitter per example was quite useless yet present on the Falcon, the 32bit CPU could easily do what the blitter did but faster, still a blitter was there for the retro-compatibility...
It seems a few operation were still advantageous with the blitter on the Falcon but not that many...

And as the TT had no blitter... it was barely compatible with the STE...

As a result, games were quite more complicated to code for those advanced STs... and would seriously need a proper recode for the many Sts variants unless you stick to the basic ST configuration...

To me the problem is that the MegaST should have been the STE/MEga STE to begin with, and the TT should have been the Falcon too...

Those pro casings would then just be an excuse to have more RAM, and proper slots to put an HDD or even additional Floppy discs (perhaps HD floppies ? or even a few extra peripherals (additionnal MIDI ports...) So the ST could stick to only 3 well defined specifications at best...

The STe AY and it's DMA stereo DAC can allow to have a really nice ingame sound w/o wasting CPU time.

Sure, to have those sounds FX in DMA samples could really give a nice stuff, then keep the 3 channels for the proper music... would need a bit more AY/YM tricks I guess (more CPU and RAM used...) or is the YM also in DMA (as on the Amstrad PLUS, sort of)  ?


I mean, most of times the games on the ST couldn't manage a more decent Music than the Amstrad because all the CPU was used by the software Sprites and scrollings...

But the YM being clocked at twice the speed as the CPC's AY, and the CPU being the 8mhz powerhouse it is, and the RAM being 512k or 1024K... clearly could do better with more CPU freed.

The ST could change the entire colour palette three times per scanline - this was used in the Spectrum 512 graphics application for example. I doubt that many games used this however - maybe for background gradients and the like.

Must use quite a load of CPU though... and be messy when you deal with scrollings and sprites...
Good solution would be to do something like the Apple // gs... you simply change the palette for the scanline... this is more than enough to get those vertical gradiants effects as with some Atari 8 bit micros and console games...



like this... but on an STe of course...

[SyX]

Pacmania could be nice too.

At your service, is one new version enough or would you prefer an x68000 port?

[Gryzor]

Whoa, looks absolutely lovely!

[fano]

Nice project this R-Type , sadly i can not test it as Steem refuses to work with my keyboard =(

I hope this R-Type will finish like our CPC version , good luck to the team 

[SyX]

Nice project this R-Type , sadly i can not test it as Steem refuses to work with my keyboard =(

I use Hatari  too and it has improved a lot in the last years (i like the debugger, it's not winape, but it's really nice).

[MacDeath]

Whoa, looks absolutely lovely!

This Pacmania is for Falcon, which i don't have (I have a pair of STe only)...
And is it me or is it as slow as the CPC's speccy port ? even more!


Ah ok, it is an emulation from the sharp X68000 (don't remember its real name)... not the best way to have it nicely done IMO...
Basically its like when we had this Arcade Pacman emulated on the CPC...  


Seriouslyy why would you need 14megs RAM to run this kind of game ?


The problem with Pacmania on the Atari ST is that it was basically a speccy port...
As for the CPC or MSX versions...


Still the AY/YM chiptunes were quite excellent (even on CPC...)

[Sykobee (Briggsy)]

At your service, is one new version enough or would you prefer an x68000 port?

Looks lovely, but it is just me or are there massive slowdowns, and a total fail to have sprite occlusion by blocks in front of them?

[MacDeath]

Yeah it clealy slows down too much, I guess it would need the Falcon to be upgraded into 32mhz CPU perhaps to run well ?


Anyway as they say at this PacMania topic, a pacmania engine is really a very trivial triviality provided your machine does have Hardware scrollings and sprites...


If done well, the "perspective" view even makes it so you never have sprites behind the background...
It could even be done on an Amstrad PLUS provided the HardSprites can be updated fast enough.


I guess it is quite manageable... As you clearly won't have to refresh every 16 sprites into a new animation frame at 50Hz...


I even guess it may be possible to simply get the background in mode1 and the sprites in Hardsprites...
The ST version uses only 4 inks for the backgrounds... perhaps it was a trick as for Ghost and goblins/wonderboy on the CPC so you can put twice more Graphical Datas, having 4 colours instead of 16...


On PLUS of course a proper mode0 background in 16 colours would definitaly be better...
The ST version could really have used a few extra colours for the background, the large half screen HUD being quite to much lavished in comparison, just the way the CPC version does have lots of Raster colours change for it while the playfield remains monocoloured... (still shitty attributes artefacts on this HUD and on the intro picture, grrrrr).


So I guess a simple PLUS version in Mode1 backgrounds and Hardsprites in fullscreen would be more than a welcomed upgrade...