DooM XL ;-)

[Allas]

Well, I found on Fandal site a file that shows something about vector engine:

 

http://atari.fandal.cz/detail.php?files_id=5474

 

Other way I have another program from Vector engine. I don't remember how I got, but I don't find in any Atari web, so I send here for the people who are interested.

 

vector_files.zip

 

There are some keys you can use in adition of the stick movement:

 

A-Jump

Z-Couch

W-Center head

S-Noad the head up

X-Noad the head down

, . - Strafe left/right

 

I think it's colorfull and have tolerable frame rate. But still doesn't have guns, IA and enemies on movement.

[Heaven/TQA]

thanks Allas...thats vector... now we have to search for the source code...

[+CharlieChaplin]

Hello folks,

and here are all the "Vector" files I have... thanks to Fandal for sending me a copy of them... put them into an ATR image...

greetings, Andreas Koch.

 

[miker]

thanks Allas...thats vector... now we have to search for the source code...

 

Maybe try Numen's homepage?

[Kaz atarionline.pl]

Improved Vector engine in action:

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

And if I remember it wasn't the best Fox could do.

Edited December 11, 2007 by Kaz atari.online.pl

[peteym5]

I have seen this demo before. If someone can get a hold of the routines, I wonder if they can adapt it to work with APAC without slowing down too much. I think one thing that allows them to run at a higher speed is not turning on the player/missile DMA and disabling the OS VBI. I personally don't like being limited to 9 colors for a game.

[Heaven/TQA]

i guess,better i am sure that Fox dissabbled OS and everything which could be steeling CPU cycles as I am using his "mini-OS" since then...

[eru]

Please, forget APAC for this type of engine:

- you can't apply the vertical-stretching with vscroll

- the DLIs will eat LOTS of the CPU time, as you have to do a DLI every line

- you would have to render two times more data

Anyway, while possible, I guess the Vector engine in APAC would run somewhere between 3 to 10 times slower.

 

The things you suggested to improve the speed (no P/M and no original VBI) are of course used in Vector/Numen already (as in pretty much every modern demo).

[peteym5]

You're right to do something in APAC would also require a lot of re-programming and customized routines.

 

I still believe creating a First Person engine with Antic 4, maybe 2 character sets for top and bottom, and DLIs is still an alternative for a higher frame rate. You will even have full or over-scan wide screen. You can have some textures, and even have extra store in memory that can be copied into the character set area.

 

Maybe I will do it myself someday, but I am only going to do a few limited games for the 8-bit. Once done, I am probably not going to do anymore, unless I make a substantial amount of money.

[emkay]

You're right to do something in APAC would also require a lot of re-programming and customized routines.

 

I still believe creating a First Person engine with Antic 4, maybe 2 character sets for top and bottom, and DLIs is still an alternative for a higher frame rate. You will even have full or over-scan wide screen. You can have some textures, and even have extra store in memory that can be copied into the character set area.

 

Maybe I will do it myself someday, but I am only going to do a few limited games for the 8-bit. Once done, I am probably not going to do anymore, unless I make a substantial amount of money.

 

Antic 4 may not be usual when forcing a char mode. Have a look at Antic 5. You have the correct aspect ratio and one charset is enough for filling the gamescreen, and it saves a lot of memory and cpu usage.

[eru]

I still believe creating a First Person engine with Antic 4, maybe 2 character sets for top and bottom, and DLIs is still an alternative for a higher frame rate. You will even have full or over-scan wide screen. You can have some textures, and even have extra store in memory that can be copied into the character set area.

I can't imagine it, so I would like to see working. Even if it's 1 fps, I'm just curious how you imagine it.

 

Maybe I will do it myself someday, but I am only going to do a few limited games for the 8-bit. Once done, I am probably not going to do anymore, unless I make a substantial amount of money.

hahaha! there's no way you can make 'substantial' amount of money programming games for Atari - any other programming job pays way better.

 

We do it for fun, not for money here

[emkay]

Maybe I will do it myself someday, but I am only going to do a few limited games for the 8-bit. Once done, I am probably not going to do anymore, unless I make a substantial amount of money.

hahaha! there's no way you can make 'substantial' amount of money programming games for Atari - any other programming job pays way better.

 

We do it for fun, not for money here

 

 

He still has the option to make a very good 3D game and take part at the yearly ABBUC Software contest. So he has the chance to win 500€ ( ~ 700 $ )

 

[peteym5]

I was going to do one Atari 8-bit game more for fun, but people jumped in there and suggested I can encode things onto a cartridge and sell them. Then I have been contacted by someone who wants me to make a few games for him. I am also aware of the Abbuc game contest and might be involved with a few submissions.

[analmux]

I still believe creating a First Person engine with Antic 4, maybe 2 character sets for top and bottom, and DLIs is still an alternative for a higher frame rate. You will even have full or over-scan wide screen. You can have some textures, and even have extra store in memory that can be copied into the character set area.

 

Have a look here. I did some demo picture of a 3d scene in august of 2003. It's a screen made up of antic 4 with 2 fonts, indeed one for the top, one for the bottom part. It's enhanced with PM Underlays. Later I converted the picture to G2F format, which I included.

 

So, I think there are some possibilities too, but maybe there still are a lot of limits. The idea I had in mind was inspired on a non-1st person game, with rotation restricted to 90 degrees.

 

Note that it's possible as well to do 'coarse' (i.e. large steps and a low framerate) movement of the playfield/background. Enemies and player can move at higher framerate.

 

So, there are lots of backup plans to do similar kinds of games, i.e. with the same gameplay, but a different graphics engine.

Edited December 13, 2007 by Analogue Multiplexer

[peteym5]

I am glad someone gets the picture of what I was thinking about for a first person point of view game. I admit it would take some work to write an Antic 4 character set based engine. I am suggesting this as an alternative if you want to keep to a higher graphics resolution. More angles also might be possible if you use extra characters and maybe additional character sets.

[fox]

Please consider that a 3D game doesn't have to be a shooter with a high frame rate.

 

Well, I found on Fandal site a file that shows something about vector engine:

 

http://atari.fandal.cz/detail.php?files_id=5474

 

Other way I have another program from Vector engine. I don't remember how I got, but I don't find in any Atari web, so I send here for the people who are interested.

 

vector_files.zip

 

There are some keys you can use in adition of the stick movement:

 

A-Jump

Z-Couch

W-Center head

S-Noad the head up

X-Noad the head down

, . - Strafe left/right

 

I think it's colorfull and have tolerable frame rate. But still doesn't have guns, IA and enemies on movement.

 

I did not release these files. They were compiled by someone from Numen sources (it's as easy as typing one "make" command once you have all tools installed). Actually there are more keys that work, for example:

J - toggles jet pack (fly with A and Z)

Space - open/close doors and use elevators

1-3 - choose a weapon (there aren't guns in Numen, but the code supports them)

 

We do it for fun, not for money here

 

He still has the option to make a very good 3D game and take part at the yearly ABBUC Software contest. So he has the chance to win 500€ ( ~ 700 $ )

 

500€ for a very good 3D game for Atari is completely nothing compared to the fun factor.

[Heaven/TQA]

Fox... how are things? Eru and you here...together with XXL some of the best 8bit atari coders around...

[happymonster]

I'm not a current Atari coder, but I think if you wanted to try to do a Doom game then like has been previously said the best approach would be to use a character based gfx mode, but with some additional tricks.

 

For example, I would do most of the walls in solid colour (with the edge boundaries using various character gfx) and then I would use a few special characters to hint at a texture. This would be a very small texture that was available at different sizes and also for some cases at 22.5% rotations and would be used on parts of the walls and floors to suggest the texture. The walls could fade out to the solid colour in the distance, so perhaps only areas close to the player would need to be considered for the 'texturing'. The texturing should avoid the very edges of walls to allow the illusion of smooth wall edges using the solid colour edge boundary tiles..

 

In this screenshot:

 

The grey walkway could be solid, the slime can be suggested by a few highlighted texture characters at different pre-created sizes (no rotation neccessary).

The wall in the background need only to be represented by the top row of squares on the top of the texture. This can be suggested with a handful of different 8 x 8 characters.

 

In this way, it's not true texture mapping, but adding relevant detail that's mostly pre-scaled in various areas to suggest detail and let our brain fill in the rest of the image.

Edited January 19, 2008 by happymonster

[Oswald]

I think reading up on the topic would help to realize how impossible is to make a doom clone. here's a step by step tutorial on how to do a wolfenstein like engine, it explains a bit of the floors aswell.

 

http://www.permadi.com/tutorial/raycast/index.html

 

the engine in Numen is a magnitude or two more complex than what the tut talks about and does already the impossible, I dont think it can get any further than that, and even that is very slow (for a game, impressive for the machine) ~5 fps.

 

using char mode would end up looking like the spectrum doom.

 

char aligned walls example from c64: http://noname.c64.org/csdb/release/?id=3248 it cheats as hard as it can, but manages to squeeze in colors in a high resolution.

 

mood is not the best the c64 can come up with here you have a playable wolf clone at the end, being roughly 2x faster than mood:

http://noname.c64.org/csdb/release/?id=11692

 

so given that the a8 is 2x faster in 4x4 modes, a smooth wolf game is more than doable.

[ZylonBane]

Someone should try creating an A8 port of Xybots. At least that would be realistically doable.

[analmux]

I think reading up on the topic would help to realize how impossible is to make a doom clone. here's a step by step tutorial on how to do a wolfenstein like engine, it explains a bit of the floors aswell.

 

You aren't the same Oswald as on the Retrogamers forum are you?

 

That thread was a short and nice readup. Didn't realise raycasting is really that simple.

 

I keep believing in charmode 3D however (like peteym5). In charmode, even raycasting makes some sense to me.

 

I just wonder if the discussed 'tests' for a ray hitting the wall can be simplified with some smart trickery. I have totally no experience in this.

[eru]

Hi Oswald, interesting to see you here

http://www.permadi.com/tutorial/raycast/index.html

That's a good tutorial, indeed, interesting how people still refer to it after so many years. I implemented my first wolf routine based on that, but I remember there were some problems due to integer computations (like +/- 1 every now and then). Still, it's quite educational to get a feeling of how much computation is necessary in a 'real' engine.

char aligned walls example from c64: http://noname.c64.org/csdb/release/?id=3248 it cheats as hard as it can, but manages to squeeze in colors in a high resolution.

Damn it, I tried to run in on Vice, and it hangs on the 'Triage' logo Any hints?

mood is not the best the c64 can come up with here you have a playable wolf clone at the end, being roughly 2x faster than mood:

http://noname.c64.org/csdb/release/?id=11692

so given that the a8 is 2x faster in 4x4 modes, a smooth wolf game is more than doable.

It indeed feels faster than Mood, and indeed, on Atari a smooth wolf engine is doable

[Oswald]

yeah I am *that* Oswald somehow I have stumbled upon this thread and I found it interesting so...

 

eru, probably you have to turn on "true drive emulaton".

 

charmode will look like the speccy doom seen on youtube, because that one does that aswell basically just without actually having a charmode built in. imagine some more colors to it, etc and you get charmode doom on xl

[Rybags]

The raycasting is virtually the same as drawing a line so far as generating iterations of the X/Y values are concerned.

 

All you need to do is AND X and Y with 7 each iteration to check if it's at a possible wall boundary (following the examples where walls are only on certain boundaries).

 

Imagine a map where walls are only on boundaries divisible by 8.

 

The map itself could be held in an array with one byte per "sector" (8x8 cell).

 

Imagine walls for a sector as being possible on the right side or bottom of the cell. That's all that's needed as adjacent cells can have walls such that a solid is formed.

 

Then, we can store the wall definition for a cell as 2 bits which can be easily tested for.

 

I'd be interested in programming something up just to see how quickly a scene could be rendered in realtime.

 

For a Doom game, we always have possible compromises - e.g. if it was done in GR. 9 then it could be interlaced, allowing PMGs to appear on the blank lines. Narrow-screen DMA would save more cycles.

 

Thus, the end result would be a viewport of 64 pixels by 40.

 

Maybe even more time could be saved by doing 32 raycast operations instead of 64. Fine-scrolling could be used between interim frames (assuming the player doesn't move forward or back).

 

A variation on the "strip softsprites" method could be employed as a quick draw routine for vertical wall sections.

[Rybags]

I'm wondering about the "corrected distance" to defeat the fishbowl effect http://www.permadi.com/tutorial/raycast/rayc8.html

 

Instead of doing those extra calculations, why aren't they just using the difference offset between player and object?

 

ie - the greater of ABS(PX-OX) and ABS(PY-OY) where PX/PY are player co-ords and OX/OY are the wall co-ords.