DooM XL ;-)

[+wood_jl]

You must have mistaken this with Doom. It was playable on a 386/40, but the framerate wasn't very good (could have been around 15 fps). Only CPUs with an FPU (like 486DX) could handle it fluently. Also if you only had 4 MB of RAM, you would experience long loading times on start of the game and between levels.

On the other hand, Wolf3D was pretty fluent on a faster 286 (16 or 20 MHz).

 

 

This is EXACTLY how I remember it. I was jazzed about building an affordable 386/40 AMD after years of using 286's and nor being able to afford a 32-bit computer, then found that DOOM was "just ok" on my new machine. Later got a DX2/66 and was more satisfied. I played Wolf3D on a 286/16 and it was great, and that's why the 386/40 and DOOM was disappointing.

[peteym5]

What if you pulled a Ballblazer?

 

Only allow turns at sharp 90 degree angles, with foward and backward movement, plus left and right strafe being the primary way of moving?

 

This simplifies calculations needed to display the playfield - if levels were adapted around it, it'd be like Doom was designed as an 8 bit original, with the original versions just adding more eye candy to the experience.

 

That is one reason why I was proposing using a character mapped screen verses doing it all vectoring, It may be possible to do it at 45 or ever 22.5 degree angles. About 16 Antic 4 lines should do the trick. Maybe do two character between the top and bottom. If done correctly, the whole screen can be rendered at a decent frame rate. You can have a bunch of textures on these characters and 5 different colors, more with a few DLIs. If you turn on the GTIA mode 10 ontop of Antic 4, you have 9 colors.

 

I am not rejecting the graphics 10 option just yet. I can see how have every set of 4 line point to the same memory with a load memory scan DL instruction. Question is do you know how to write a fast rendering routine?

 

I cannot agree totally that APAC eats up all the clock cycles. My work around has DLI routine code looking like this:

 

DLI1:

PHA

LDA #64

STA WSYNC

STA PRIOR

LDA # >DLI2

STA 512

PLA

RTI

 

DLI2:

PHA

LDA #192

STA WSYNC

STA PRIOR

LDA # >DLI1

STA 512

PLA

RTI

 

Set a DLI bit on about 160 ANTIC 15 lines, and just set the high byte once (513). This will switch between graphics 9 & 11 giving us an APAC screen, and do it along with the Display List setup for 4 pixel tall method. After this u have most of your clock cycles remaining. I probably can write a small demo to test to see how fast things still run in this mode. However I am tied up with other projects right now. Hope someone else can do this.

Edited December 9, 2007 by peteym5

[Mr.Amiga500]

After the A8 DOOM is done, the next step is DOOM on the 2600. Then of course, I'd like to see DOOM on the Xerox line-plotter. Anything beyond that would just be silly.

[peteym5]

After the A8 DOOM is done, the next step is DOOM on the 2600. Then of course, I'd like to see DOOM on the Xerox line-plotter. Anything beyond that would just be silly.

 

Thats Funny. Why not do a Vic-20 and Timex Sinclare ZX81 version. You know honestly I rather concentrate on projects of what the Atari can do. I think people want to do this just because someone did a C64 version and now they need one for the Atari. I tried to give everyone a few pointers. I say go for a much simpler 1st person shooter. Wonder if they will submit it this year for the ABBUC contest.

 

Wolf3D and DOOM really requires 256 colors on at least a 16bit cpu running much faster than a 6502.

[Rybags]

You don't need 2 DLIs for APAC.

 

It can be a simple case of maintaining a shadow of GPRIOR in Zero-page.

 

Then it's just:

 

PHA

LDA ZPRIOR

EOR #$80

STA ZPRIOR

STA WSYNC

STA GPRIOR

PLA

RTI

 

Also, no need for repeating LMS instructions to do 4 pixels - it is more cycle efficient to just use the VScroll trick to fool ANTIC into drawing the same scanline 4 times with only 1 sweep doing DMA.

 

But: back to APAC - it would be very cumbersome to do a bitmapped APAC game at 80x96 resolution. However, 80x48 (APAC with "square pixels") might be easier, although you cop the DMA penalty as ANTIC has to re-read data every line.

 

Maybe APAC in narrowscreen, with repeated lines for square pixels (64x about 40 high). In narrowscreen the DLI could be optimised - use NOPs instead of WSYNC would free up a few cycles per line.

Edited December 10, 2007 by Rybags

[Allas]

- it is more cycle efficient to just use the VScroll trick to fool ANTIC into drawing the same scanline 4 times with only 1 sweep doing DMA.

 

What's that?

[Rybags]

In bitmap mode (e.g. Gr. 8 ), with GPRIOR set for whatever GTIA mode you want.

 

In the DList you have VSCROLL set for every second instruction.

 

Then, you have a DLI every instruction.

 

Alternate the VScroll register value between 12 and 3

 

Antic will then redisplay 3 extra scanlines - as per the documentation:

 

For the first cell of a scrolling region, DCount will count from VScroll to (number of lines for the mode -1).

For the last cell of a scrolling region (ie VScroll bit is not set), DCount will count from 0 to VScroll value.

 

The trick is that in bitmap modes, it will just redisplay the first line rather than fetching new data in the character modes. Check the Numen demo, it's used there in it's GR. 10 square pixel mode).

 

A cheap way of doing graphics - sure you lose some cycles with the DLIs, but it pales into insignificance considering that you save 40 cycles for each redisplayed scanline, plus probably 3 more since you're not relying on an LMS instruction to redisplay the same data.

Edited December 10, 2007 by Rybags

[Allas]

In bitmap mode (e.g. Gr. 8 ), with GPRIOR set for whatever GTIA mode you want.

 

In the DList you have VSCROLL set for every second instruction.

 

Then, you have a DLI every instruction.

 

Alternate the VScroll register value between 12 and 3

 

Antic will then redisplay 3 extra scanlines - as per the documentation:

 

For the first cell of a scrolling region, DCount will count from VScroll to (number of lines for the mode -1).

For the last cell of a scrolling region (ie VScroll bit is not set), DCount will count from 0 to VScroll value.

 

The trick is that in bitmap modes, it will just redisplay the first line rather than fetching new data in the character modes. Check the Numen demo, it's used there in it's GR. 10 square pixel mode).

 

A cheap way of doing graphics - sure you lose some cycles with the DLIs, but it pales into insignificance considering that you save 40 cycles for each redisplayed scanline, plus probably 3 more since you're not relying on an LMS instruction to redisplay the same data.

 

Incredible! thanks

[peteym5]

I have to try these tricks myself. I have been looking into ways to make use of animation in APAC mode. I admit I am not looking to use APAC immediately for a Doom like game. Have been considering it for something simpler like Tetris, Columns, or puzzle games that dont require high speed animation.

[emkay]

After the A8 DOOM is done, the next step is DOOM on the 2600. Then of course, I'd like to see DOOM on the Xerox line-plotter. Anything beyond that would just be silly.

 

Hm.... The 2600 is mainly half of an ATARI 800.

And the funny thing is: A "DooM" is already running on a computer with the "half" of CPU powers

 

Have you taken a look at the conversion project of Space Harrier?

 

http://de.youtube.com/watch?v=K254b2V0qAA

 

The game looks like someone put a hardware blitter in. But it's all done by software and the "simple 6502"...

 

MooD on the C64 runs in 1/8 of the resolution of Space Harrier on the A8.

[Mr.Amiga500]

Wolf3D and DOOM really requires 256 colors on at least a 16bit cpu running much faster than a 6502.

 

Well, DOOM still looks pretty good with 64 colours (as in Amiga Halfbright mode) - even 32 would be OK. Low-res 16 colour would look very crappy (especially in those levels with lots of browns, greens and reds). Even if that crappy mode was possible, it's still not really DOOM unless it uses the official DOOM wads right? The original DOOM wad is 12Mb. Is is possible to page parts of that wad into RAM when playing and still run the thing at a reasonable speed - on a 6502 with 64k/128k?? Yeah, you can make a "DOOM-like" game that doesn't use the DOOM wads, but then it's not really DOOM. So the impressive statement "I've got DOOM on my A8!!!!1" is really an impossibility.

 

Still, if somebody ever did make even a single-level A8 DOOM (with stripped-down wad), I'd be very impressed and congratulate them as a hero of mankind. (...then I'd ask them to make Half-life for my Amiga 500 )

[emkay]

Well, DOOM still looks pretty good with 64 colours (as in Amiga Halfbright mode) - even 32 would be OK. Low-res 16 colour would look very crappy (especially in those levels with lots of browns, greens and reds). Even if that crappy mode was possible, it's still not really DOOM unless it uses the official DOOM wads right?

 

No! It is DooM, if the "feeling and playability" of DooM is there.

 

The original DOOM wad is 12Mb. Is is possible to page parts of that wad into RAM when playing and still run the thing at a reasonable speed - on a 6502 with 64k/128k?? Yeah, you can make a "DOOM-like" game that doesn't use the DOOM wads, but then it's not really DOOM. So the impressive statement "I've got DOOM on my A8!!!!1" is really an impossibility.

 

Who made that rule, you?

 

Look. Space Harrier, or Out Run, or Gauntlet ... or...

They are not basically like the originals, but they are "Originals" on the C64. And all they have in common with the orignals is the "game-style".

 

Look at Space Harrier again: The "feeling and playability" of the original is still in the A8 version, even after reducing the data into the capabilities of an 8 bit computer.

 

Still, if somebody ever did make even a single-level A8 DOOM (with stripped-down wad), I'd be very impressed and congratulate them as a hero of mankind. (...then I'd ask them to make Half-life for my Amiga 500 )

 

Well.... For the AMIGAs with ECS Chipset, development on Fastmem is strongly recommended.

Possibly some fluent "Voxel" based 3D is available when using Fastmem for the program itself and using the Chipmem for Texture memory. And there is an advantage and a disadvantage on ECS machines:

The disadvantage is the slowdown of the chipmem, when the copper is working. The advantage is the scaling ability of the Blitter.

The main "idealistic" difference between the AMIGA and the A8 is that the A8 has the "same" Processor and speed from 400 to 130XE, while the AMIGA changed the chipset several times and had CPU upgrades.

People who needed 3D, used an A3000/4000 Amiga. So, perhaps, you might never see any good 3D rendering on a OCS/ECS machine, because there is no achievement into it.

On the A8 we have Numen, Reditus, the Shrine and other 3D renderer...

Edited December 10, 2007 by emkay

[Mr.Amiga500]

Who made that rule, you?

 

Uh... yeah... I guess I did. I suppose I was thinking that way because on every OS I played DOOM - Windows, MS-DOS, BeOS, Linux, Amiga - I used the exact same set of wad files. I briefly forgot the hundreds of other game conversions which don't use a single similar file across platforms. So yeah, I guess my rule is stupid.

[Heaven/TQA]

(again) for the guys who are interested regarding the "VSCROLL"-trick:

 

http://www.s-direktnet.de/homepages/k_nadj/mode9++.html

 

and check out the 40x40 gr.0 mode:

 

http://www.atariage.com/forums/index.php?s...p;hl=mode+40x40

 

this is all information imho which should be preserved somehow...

[Chrodegang]

Check this at 2:22:

 

http://de.youtube.com/watch?v=bEh48llWmyY

[A Sprite]

Check this at 2:22:

 

http://de.youtube.com/watch?v=bEh48llWmyY

 

No enemies, no gunplay, no AI, no doors, no user input. Good demo, but the trouble isn't getting the Atari to play Doom, it's letting the players in on the action.

 

That said, I wonder how hard deathmatch alone would be as a trial? 1st person shooters have been doing it since before home computers existed.

Edited December 10, 2007 by A Sprite

[JamesD]

After the A8 DOOM is done, the next step is DOOM on the 2600. Then of course, I'd like to see DOOM on the Xerox line-plotter. Anything beyond that would just be silly.

 

Hm.... The 2600 is mainly half of an ATARI 800.

Not even close.

[ThomSW]

No enemies, no gunplay, no AI, no doors, no user input...

 

Yeah, we're waiting for you. What will YOU do for it, eh?

[peteym5]

Check this at 2:22:

 

http://de.youtube.com/watch?v=bEh48llWmyY

 

Nice Demo, but can you get this shadow guy to write something that can be used for a first person shooter?? Demos are nice, but would need to have one of those programmers release how they do some of that stuff.

Edited December 10, 2007 by peteym5

[A Sprite]

No enemies, no gunplay, no AI, no doors, no user input...

 

Yeah, we're waiting for you. What will YOU do for it, eh?

 

Cheer on from the sidelines while people who can speak hexidecimal figure out how it could actually be done.

 

I learned in the Jag forums not to trust a demo as a test of a machine's capabilities. Doing everything in that demo, plus running a game, and keeping a playable frame rate isn't as easy as asking the programmers here to cut and paste the code, even if it was given to them.

 

Not saying that kind of graphics can't be done for a Doom port, only that the verdict still isn't in.

 

If you're asking me to help or get out of the way - tell me what the engine can do, and I'll custom design every graphic you need, free of charge.

Edited December 10, 2007 by A Sprite

[eru]

Nice Demo, but can you get this shadow guy to write something that can be used for a first person shooter?? Demos are nice, but would need to have one of those programmers release how they do some of that stuff.

There are some demo sources are also released, e.g. Numen.

And it contains Vector, is pretty much the Doom (actually DukeNukem) engine everybody's asking for.

 

And about the Asskicker, it's slowish

[peteym5]

Nice Demo, but can you get this shadow guy to write something that can be used for a first person shooter?? Demos are nice, but would need to have one of those programmers release how they do some of that stuff.

There are some demo sources are also released, e.g. Numen.

And it contains Vector, is pretty much the Doom (actually DukeNukem) engine everybody's asking for.

 

And about the Asskicker, it's slowish

Pages? Links? Download where?

[eru]

http://numen.scene.pl/download.html

[Heaven/TQA]

Eru...did we ever release the vector sources as well? unfortunatly i lost my emails with the demo and i guess we send around the sources as well or are they not here on the boards somewhere?

 

yup...i just went through my email archive and i lost all emails we send during the numen coding sessions... only stuff i have found is the GBA stuff (the TQA bump mapper...)

Edited December 10, 2007 by Heaven/TQA

[eru]

I actually don't remember if Vector has been released separately - but there used to be MANY threads about it here, just search for 'vector' in thread titles on AtariAge forums.