arcade2atari8 [asteroids]

[xxl]

i still belive in a small vbxe core update

 

http://xxl.atari.pl/?page_id=130

http://atariarea.krap.pl/forum/viewtopic.php?pid=118938#p118938

[+MrFish]

Does that mean it will be VBXE only, or just that you're waiting for the "core update" so that you can finish the VBXE version?

[13matt]

This was the most amazing project yet on the Atari in my opinion, as I have always longed for better versions of those arcade greats for the A8

 

I do hope we can see this completed soon, and wait for further similar projects:

 

Space invaders

Lunar Lander

Moon Cresta

Galaxian

Galaga

 

too many to list really lol

[Synthpopalooza]

I think a good version of Galaxian would look great ... I've been working on some fonts for Galaxian using Super IRG which I think look real close to the arcade. as I recall, Bill Kendrick (who created the Super IRG Gem Drop game) suggested Super IRG would work for Galaga.

 

I also think some chap over on the 7800 forum is doing his own version of Moon Cresta.

 

I would add Phoenix to the list, but it seems DearHorse (AtariTools) is working on that one ...

[peteym5]

Has anyone started a Galaga port to Atari yet? I have given this some thought of how to make a good port Atari 8 conventional graphics. Super IRG is one possibility. The other I thought about was making black as one of the foreground colors and one of the colors like red as black, and place player/missile graphics behind for extra colors (Setting Prior to . The third possibility is setting Prior to 0 that will OR screen colors and player/missile colors. Using Antic 4 mode, we are going to have 127 characters to do the graphics. Will it be enough?

[Rybags]

I've given some thought.

The idea I have is a dynamically changing Display List so that the swelling/contracting of the pack can be sped up.

 

If using text mode, I have real doubts 128 characters would be anywhere near enough. In any case, it's low on the list of technical barriers to overcome.

Additionally, VScrol tricks + dynamic DList could be used in character mode.

 

It's the sort of thing though that'd need proof-of-concept for both cases.

 

The problem with Galaga though... practically every attempted home version or clone utterly sucks except for the NES one. Not much point anyone putting months of effort to add to the negative side of the ledger.

 

Another idea I had was to just take the NES code and adapt to VBXE. But I've got 2 or 3 projects ahead of even contemplating so, and I don't know much about the NES graphics hardware.

[+MrFish]

Here's a test I did some time back to see what the sprites for Galaga might look like on the Atari:

 

5 Colors + 1 Background + 1 Beam

 

[peteym5]

Looks interesting. I have been looking at different ways of doing it on the Atari. However I already involved with other stuff myself. I cannot start up another project and do all the programming myself. But I think it is possible to get the onscreen colors necessary. I prefer ANTIC 4 mode because it takes less CPU time to move things around.

 

How do you do those VScroll and Dynamic Display List tricks? I know someone did a different font size like 4x4 characters awhile back but I am not sure how he did it.

[+Stephen]

Here's a test I did some time back to see what the sprites for Galaga might look like on the Atari:

 

5 Colors + 1 Background + 1 Beam

 

Wow - that looks great.

[+MrFish]

Looks interesting. I have been looking at different ways of doing it on the Atari. However I already involved with other stuff myself. I cannot start up another project and do all the programming myself. But I think it is possible to get the onscreen colors necessary. I prefer ANTIC 4 mode because it takes less CPU time to move things around.

 

How do you do those VScroll and Dynamic Display List tricks? I know someone did a different font size like 4x4 characters awhile back but I am not sure how he did it.

 

Wasn't the source code for Galaxian on the 5200 released by Curt V. at some point?

 

Wow - that looks great.

 

Thanks. I think I pushed the upper and lower vertical limits too far out though -- too much would get clipped on a real monitor.

[GroovyBee]

Wasn't the source code for Galaxian on the 5200 released by Curt V. at some point?

 

http://www.digitpress.com/library/techdocs/5200_Galaxian_source.zip

[Bryan]

Here's a test I did some time back to see what the sprites for Galaga might look like on the Atari:

 

5 Colors + 1 Background + 1 Beam

 

 

In Antic mode 4 you get 5 colors total, including the background. A DLI between the rows would take care of the colors needed for each row, so the alien formation isn't the problem. The problem is the large number of multi-colored sprites the game can have in motion (attacking or flying in from the top) at any time. It's going to be tough to do it all and make it look good.

[Rybags]

VScrol trick in Mode 4 - same deal as the text modes with shortened characters.

 

Dynamic DList - in Mode E, have extra lines with LMS at the start of those that get inserted. The softsprite routine would also need a table with start address for each YPos, although this adds to the rendering time.

 

Another strategy is just use straight up Mode E and use the "Space Invaders" arcade strategy - only move a few formation aliens per frame. With it all happening at 50/60 FPS the result would be reasonably smooth.

 

The multicolour display looks nice but I'm not sure it'd work in reality. PMG underlays add yet more time and with all the moving objects, colour clash and running out of PMGs would be a sure thing.

[kogden]

 

I totally don't get the point of the VBXE..

 

I'm mainly interested in one just for a noise-free display on modern TV's and maybe a CRT VGA monitor. The added goodies are cool too. I don't see issue with VBXE-enhanced software, I'd rather it be an additional feature for something like this though.

 

Most video output from these machines is downright awful on anything modern and old TV's are dropping like flies. I haven't found a s-video->VGA adapter yet that didn't look like crap with the Atari :-/. I have a couple different models too.

 

Hopefully the frame rate can be brought up on stock hardware, that's pretty awesome. Was always unimpressed with the Atari Asteroids conversion. Multiplayer was fun I guess.

 

I had actually considered a project similar to this but actually using a real vector generator attached to the PBI to drive a vector screen with the Atari. They had one that plugged into the PC parallel port a few years ago.....Zektor ZVG I think it was called. You could really do some smooth games with the little 1.79MHz 6502 with a vector screen. Would be cool to utilize built-in display hardware as secondary display too. I wish a good source of vector screens still existed. A Star Raiders and/or Flight Simulator clone could be killer with such a setup and quite fast.

[Rybags]

You don't have to sell him the idea, I think he's got a VBXE now.

 

Many of the Atari vector games run significantly slower CPU speeds than the computer, although they'd likely be suffering a lot less DMA penalties.

 

An alternate VBXE core could emulate a vector processing system.

Building one from scratch, I don't see much point - finding monitors would be next to impossible.

[kogden]

You don't have to sell him the idea, I think he's got a VBXE now.

 

I don't yet, I still want one though. Just don't have the spare cash at present.

 

Many of the Atari vector games run significantly slower CPU speeds than the computer, although they'd likely be suffering a lot less DMA penalties.

 

While game scenes needed to be less complex, keeping track of a few points is probably easier than moving sprites around or redrawing bitmaps as well.

 

An alternate VBXE core could emulate a vector processing system.

Building one from scratch, I don't see much point - finding monitors would be next to impossible.

 

Hell you could likely do a simple 3D accelerator as a VBXE core with a little effort.

 

Finding working Ataris and CRT TV's will one day be next to impossible too. Won't mean I won't be looking for a way to hook some old gear up to my quantum computer with liquid RAM. The point of a hardware vector interface would be to have that insanely bright cool analog display. Never said it would be practical. Arcade tubes can be dug up here and there. With a lot of work you could convert a regular CRT into a vector monitor. Or salvage a dead Vectrex.

[peteym5]

Going over the possible ways to do Galaga, maybe SuperIRG be a better option. That is to get extra colors, use a flickering checkerboard. Its notmuch noticable with darker colors that are near the same luma level. Like Red and Blue can make purple. If we use Antic 4 Fonts. Can do the ships with some half shifted down at diangles. Simulate movements 4 pixels at a time. I would have to look at some source code and view some programs that use that VScroll trick. If someone can set something up with shortened characters, won't need to have characters half shifted down.

 

On the subject of Vector games, I was discussing with KJMANN12 the ideal of making a better version of Star Wars arcade with an enhanced line draw routine I used for Tempest Extreme. I estimated it can draw several lines within one frame. I can probably tweak it further, but I think it has to be able to render everything at least 15 frames per second to keep it looking good. Currently it may be falling short to meet that requirement. Maybe do a game that has a less stuff moving around on the screen.

 

I once thought about "Omega Race" or something similar. Maybe my Sprite Multiplexer be a better option with such a game over line drawing or softsprites. My similar clone of "Omega Race" was based on the ideal of different boxes to bounce off of on the screen that will be in different locations each level, along with the forcefields along the edge of the screen. I tried making it in Turbobasic many years ago, but was limited to 2 or 3 enemies. With an all ML game, I could do better than 10.

Edited February 23, 2012 by peteym5

[Rybags]

"Several lines" doesn't quite cut it.

 

I've investigated quicker line-draw, the fastest seems method seems to be to do 2 pixels per iteration starting at origin and endpoints and meet in the middle.

One idea I had was to dispense with some of the lookup stuff and instead directly manipulate the address and plot value.

 

The thing with line-draw for vector games - it's in many cases just quicker to render a softsprite with the same image so in a game situation a mix of both would probably work best.

 

SuperIRG - not a fan of it here. I think I'd rather have less colour than put up with annoying flicker in a moving game.

For stuff like static title screen pics, a bit of flicker is OK. For most games, not acceptable.

[peteym5]

I looked at my linedraw routine and do see where the cpu usage can be cut down. I thought about softsprites for smaller stuff, and line drawing for the bigger stuff. It does take up a lot of memory to store each bit-shift for some of those things.

 

I am experimenting with SuperIRG type graphics for an Adventure type RPG game for the stuff not moving like walls, doors, items, etc. But that stuff is static, probably won't work as well if it has to move around. I don't think SuperIRG would work well with a scrolling game also. It is not noticeable if the alternating pixels are bundled with brighter non alternating pixels. Like if a few Red/Blue = Purple pixels have more white pixels next to it.

[Rybags]

What might work with Galaga is cycling 2 pixel values with similar luma, different colour to achieve a perceived 3rd colour.

 

e.g. Yellow and blue to get green. But that means there needs to be a whole extra set of shifted softsprites, although the masks can be shared.

 

Although the problem arises - those particular sprites then need to be rendered every frame even if not moving.

Might work for the fleet "bosses" though since there's only 4 of them.

Edited February 23, 2012 by Rybags

[+MrFish]

Here's a test I did some time back to see what the sprites for Galaga might look like on the Atari:

 

5 Colors + 1 Background + 1 Beam

 

 

In Antic mode 4 you get 5 colors total, including the background. A DLI between the rows would take care of the colors needed for each row, so the alien formation isn't the problem. The problem is the large number of multi-colored sprites the game can have in motion (attacking or flying in from the top) at any time. It's going to be tough to do it all and make it look good.

 

Here's a color reduced version. No white on the enemies and the extra green has been removed from the beam:

 

[peteym5]

Has there been any further updates for that Asteroids game? Ever completed?

 

For Galaga, I suggest do some screen tests with different methods on an Atari emulator to see what works. What would be easier to animate, draw, etc. Antic 4 with player missile graphics probably be the best shot for native hardware. VBXE will it accurately without no problems.

 

Doing a game like Star Wars arcade, would require some fast line draw routines. I have to tweak and experiment with the one I've been using. I played around with some self modifying code to see what is possible with Tempest, but that game had static graphics for the web. I probably will do a game that is less moving object intensive first. I am not sure what the second Star Wars game on the A8 used. Did it use a custom routine or called the OS.

[peteym5]

Here is a test of how fast I can get my line drawing routine going. It is erasing and redrawing 12 lines. The routine uses table lookup and self modifying code. I build my stuff around a graphics 15 screen. Frame rate is going to be effected by number and length of lines on the screen. I do believe it is faster than the Atari OS routines. I am still conservative about doing any intensive vector arcade port to Atari. Have to also keep into account of any massive calculations like 3D positioning or Trigonometry. Doing a game like Star Wars Arcade (Again!) is tough and don't think anyone can do much better than that 2nd one made for the Atari. Those are games that have stuff moving all the time. There are games where stuff remains steady (Like Tempest or Black Widow) and the moving stuff can be done with Player/Missile graphics.

 

I did mention Omega Race, but maybe using combination of a Player/Missile Multiplexer and Soft Sprites would work better because there is a lot of small stuff moving there.

linetest.xex

[Rybags]

Just about anything will be faster than the OS routines. They're too generic, what slows them down is the CIO overhead, 2 bytes for X-Pos, the fact they're mode independant and the calculation of addresses rather than using table lookup.

 

There's a certain critical mass for a line-draw to be quicker than just doing softsprite in a vector game although that said, a set of vectors for an object can be much more memory efficient than a set of preshifted shapes and masks.

 

Line drawing with VBXE can potentially be the fastest of anything. Partly due to being able to run with practially no DMA, and also due to being byte oriented which can make the code path shorter.

 

I don't have the links but the C= scene has investigated quick line draw and it would seem the best method is the "start at the ends, meet in the middle" technique.