240 replies to this topic

[miker]

xxl, on Fri Dec 24, 2010 4:33 AM, said:

$420, level without textures, and then 'corridor' level and stuck

Similar here - $170 and no keys.

[ctirad]

Awesome work, NRV!

Although, the PAL version probably needs to fix colors. The green doors are actually blue and I hardly see the difference between the them and the regular blue doors.

[Yosh]

When I saw a "rotating 3d perspective preview" I thought it's super nice, even that he will be never able to add walking. What a small faith I was.

It's awesome now - one of the best xmass present for me. I salute you!

[Sheddy]

I always wondered how these types of games were done, but I never imagined they'd be possible on 8-bit at such a good frame rate with such a large display. And with APAC! Amazing stuff. Even Doom on Sega 32X had very small window.

[emkay]

miker, on Thu Dec 23, 2010 3:03 PM, said:

Superb work!

Thanks NRV for continuing the project.

@analmux: thanks, I tried my best.

It's really a good one. Graphics and Sound remind strongly of the PC version.

[NRV]

Heaven/TQA, on Fri Dec 24, 2010 1:25 AM, said:

oh... it is 64k? I can add my RPG battle engine from Beyond Evil and we have 3d Diablo-like RPG.

Let me add a working enemy and let's see what we can do
In reality, I have an idea for another raycaster that will be better suited to that kind of "dungeon" game. As much as I like this one, I believe that the "sweet spot" for this "technology" is other graphic mode, with proper pixel resolution, fewer screen columns, less texture detail and with lot of "light effects" (depth cue, reflections?, some kind of bump mapping for walls?).. hope to get that working someday

emkay, on Fri Dec 24, 2010 1:42 AM, said:

NRV, you are crazy..

I get that a lot

analmux, on Fri Dec 24, 2010 4:06 AM, said:

Heaven/TQA, on Fri Dec 24, 2010 1:25 AM, said:

oh... it is 64k? I can add my RPG battle engine from Beyond Evil and we have 3d Diablo-like RPG.

The version without intro only needs 44kB. I suppose it is a non-crunched file.
(EDIT: After still thinking)
However, I also suppose the free 18kB is needed for unpacking unrolled routines & other workspace, gfx memory etc?

The intro start loading at 16K and later the main game just overwrite all of it. The main program uses all memory from 10K and up, so you need at least 52K to run it (8K of those are the double buffer screen area). I'm not using any kind of compression yet.

xxl, on Fri Dec 24, 2010 4:33 AM, said:

$420, level without textures, and then 'corridor' level and stuck

Great! someone saw the "dark" levels (I hope that the second dark level will be very scary if I add some enemies.. by the way that was a fast hack, the engine is doing the same work that with the "textured" levels, if programmed correctly those levels should run at a very good frame rate).

Sorry the corridor level is the last one and is mainly there to get the last treasures, and to show a long "matrix-like" corridor with the engine .

At the start I had only the first level (a maze of 32x45 tiles) and I wanted to add more levels, but don't have enough memory. So I created some kind of "language" to generate mazes by code. The maps 2,3 and 4 have areas of 28x20, 31x19 and 26x10 tiles, but use only 131, 137 and 86 bytes!

miker, on Fri Dec 24, 2010 5:06 AM, said:

Similar here - $170 and no keys.

There are 4 secret "areas" in the first level with some of them already in the videos (one "area" can have more than one secret..). There are only 2 keys hidden, but you only need the second one if you want the high score .

ctirad, on Fri Dec 24, 2010 5:06 AM, said:

Although, the PAL version probably needs to fix colors. The green doors are actually blue and I hardly see the difference between the them and the regular blue doors.

Yes, they are consecutive colors. The green is in reality a "blueish-green", I should have used a proper green I suppose.

Sheddy, on Fri Dec 24, 2010 6:48 AM, said:

I always wondered how these types of games were done, but I never imagined they'd be possible on 8-bit at such a good frame rate with such a large display. And with APAC! Amazing stuff. Even Doom on Sega 32X had very small window.

Many years ago I used to think that all things should run at 60 (50 in PAL) frames per second, if not they were not "valuable".. and then I saw Space Harrier running and it opened my eyes

I should say that this project was a constant "surprise" for me. I started with a "what if..", trying to do things that I didn't know if they were to work at a decent frame rate.. and they worked! every one of them.. I don't know if I should talk about luck here

The other day I was starting to think that maybe something like doom, but without textures, will be possible (that and like 10 other projects that I have in my head..)

By the way I still have an optimization to add that could give a boost to the frame rate. Is a little complicated because of my last changes to the code, but worth a try if I want to implement another kind of raycasters later. Basically it consists in tracing the rays not form left to ray of the screen, but applying a kind of "binary search" to the process. Is based in the fact that if 2 different rays collides with the same wall, you know that all the rays in between those 2 rays collides with the same wall. So you can interpolate the final height for those columns (you still need some calculations to get the texture coordinate, but you can do them a little faster also).

Try holding [shift] when the loading ends and the main game start, to see a better frame rate working!

Regards and Merry Christmas to all!

[Jacques]

NRV, on Fri Dec 24, 2010 11:18 AM, said:

Let me add a working enemy and let's see what we can do
In reality, I have an idea for another raycaster that will be better suited to that kind of "dungeon" game. As much as I like this one, I believe that the "sweet spot" for this "technology" is other graphic mode, with proper pixel resolution, fewer screen columns, less texture detail and with lot of "light effects" (depth cue, reflections?, some kind of bump mapping for walls?).. hope to get that working someday

For me, the 1:1 Wolfenstein 3D conversion with the graphics as this kind of gfx would be just enough and a dream coming through! The game is open-source now AFAIR, so the maps should be convertable?
Imagine, "real" Wolf on A8!

Anyway, you gave us all really stunning Christmas gift, thank you and Merry Christmas!

[analmux]

NRV, on Fri Dec 24, 2010 11:18 AM, said:

...

analmux, on Fri Dec 24, 2010 4:06 AM, said:

...The version without intro only needs 44kB. I suppose it is a non-crunched file.
(EDIT: After still thinking)
However, I also suppose the free 18kB is needed for unpacking unrolled routines & other workspace, gfx memory etc?

The intro start loading at 16K and later the main game just overwrite all of it. The main program uses all memory from 10K and up, so you need at least 52K to run it (8K of those are the double buffer screen area). I'm not using any kind of compression yet.

Sorry, didn't read properly. You already explained before, in post 33.

I wonder whether you're using self-modifying code and what's the total amount of RAM workspace you need.

I would try to aim at the standard 800XL. Then the main code part can be burned into ROM, let's say a cartridge. Then there's still plenty of RAM left. However, you'd need to do 16kB banking then. Not sure if this would work without problems.

In theory it should even work on the 800, but I suppose you're using a very fast custom routine for generating the APAC mode, just to leave some time for intermediate processing, when TV-beam is on-screen. So, there's no way to write custom NMI & IRQ handlers ($fffa & $fffe can't be changed).

[w1k]

looool
i played PM about 3 hours today.. if i turn my atari nothing do.. I HOPE IT IS POWER SUPLY

edit: yes, it was PS.. i try another

Edited by w1k, Fri Dec 24, 2010 3:50 PM.

[Irgendwer]

Very, well done!

NRV, on Fri Dec 24, 2010 11:18 AM, said:

...
By the way I still have an optimization to add that could give a boost to the frame rate.
...

A very simple 'optimization' which
+ results in nearly double speed
+ saves half of the texture memory
+ saves half of needed screen memory
but
- needs more 'fine tuned' textures and
- takes away a bit of visual variety

consists in just mirroring the display on the horizon line by display list.
(PM enemies, of course, wouldn't suffer from it.)

Demo could be insightful...

Keep it up!

Edited by Irgendwer, Fri Dec 24, 2010 4:03 PM.

[NRV]

w1k, on Fri Dec 24, 2010 3:42 PM, said:

looool
i played PM about 3 hours today.. if i turn my atari nothing do.. I HOPE IT IS POWER SUPLY

edit: yes, it was PS.. i try another

haha sorry, I hope is not "my" fault

here, a little help:

Irgendwer, on Fri Dec 24, 2010 4:02 PM, said:

A very simple 'optimization' which
+ results in nearly double speed
+ saves half of the texture memory
+ saves half of needed screen memory
but
- needs more 'fine tuned' textures and
- takes away a bit of visual variety

consists in just mirroring the display on the horizon line by display list.
(PM enemies, of course, wouldn't suffer from it.)

Yeah.. the Alternate Reality (the city) "way".. I'm still resisting to it
But it's an option.. the only problem is that it will force me to use the same colors for the floor and the ceiling (hmm.. I could have some mirrored software sprites also.. like columns).

[w1k]

NRV, on Fri Dec 24, 2010 4:25 PM, said:

w1k, on Fri Dec 24, 2010 3:42 PM, said:

looool
i played PM about 3 hours today.. if i turn my atari nothing do.. I HOPE IT IS POWER SUPLY

edit: yes, it was PS.. i try another

haha sorry, I hope is not "my" fault

here, a little help:

Irgendwer, on Fri Dec 24, 2010 4:02 PM, said:

A very simple 'optimization' which
+ results in nearly double speed
+ saves half of the texture memory
+ saves half of needed screen memory
but
- needs more 'fine tuned' textures and
- takes away a bit of visual variety

consists in just mirroring the display on the horizon line by display list.
(PM enemies, of course, wouldn't suffer from it.)

Yeah.. the Alternate Reality (the city) "way".. I'm still resisting to it
But it's an option.. the only problem is that it will force me to use the same colors for the floor and the ceiling (hmm.. I could have some mirrored software sprites also.. like columns).

thanks for map, tommorow i try it

[patarik]

Superior work!!!!

Thanx and pls continue with the project.

[emkay]

NRV, on Fri Dec 24, 2010 4:25 PM, said:

Yeah.. the Alternate Reality (the city) "way".. I'm still resisting to it
But it's an option.. the only problem is that it will force me to use the same colors for the floor and the ceiling (hmm.. I could have some mirrored software sprites also.. like columns).

I'd leave it as it is. Depending on the shown screen content and the variety of the available 16 luma steps, there is a subtle impression of the "PC Wolf 3D" that would be missed when using the mirroring.

One thing could get even more impressive. Depending on the count of enemies, you want to show on the screen. It would be even more outstanding when PM-graphics could be used to enhance the enemies.

Not sure how it all works. But here some "eyes" , there some details on the weapons... in higher resolution than APAC. It would be "the killer"

[www.atarimania.com]

Fantastico!

--
Atari Frog
http://www.atarimania.com

[Irgendwer]

NRV, on Fri Dec 24, 2010 4:25 PM, said:

But it's an option.. the only problem is that it will force me to use the same colors for the floor and the ceiling.

Not mandatory. I know that changing the colour registers in the GR.9/11 mode doesn't help much, but changes are possible with some limitations: Demo one below shows colour remapping for the first 8 entries (biggest problem loss of black/grey shades on one half of the screen). Second demo shows gradient colour effect by modifying base lightness for BCKCOL in Gr. 11.

Especially when changing from 11 to 10 (with the perceived resolution enhancement), ceiling floor colour change on the horizon line would be easy (conflicts with PM colours taken aside).

Edit: Emulation (Atari 800 Win+) depiction is not correct for the 'ECKN+' image on the right side! Will post better example soon.

Attached Thumbnails

• 
• 

Edited by Irgendwer, Sat Dec 25, 2010 6:20 AM.

[w1k]

i found next level.. in black corridor is i the KEY, that you need for the right of maybe 10 doors



hm, maybe 10 doors, but only one key?

Edited by w1k, Sat Dec 25, 2010 6:42 AM.

[Irgendwer]

Irgendwer, on Sat Dec 25, 2010 6:10 AM, said:

Edit: Emulation (Atari 800 Win+) depiction is not correct for the 'ECKN+' image on the right side! Will post better example soon.

Real TV screen-shots:

Attached Thumbnails

• 

[Rybags]

I've found that using luma level 2 on the "colour" lines is perfectly acceptable, even produces better results sometimes.

It might be worth experimenting with that especially in NTSC - you'd probably get "better" perceived colour-blending if the luma was a bit higher.

[Kaz atarionline.pl]

Nelson, amazing piece of software, congratulation!

PAL version recorded from Altirra 1.8, presenting HUD display, Atari Rainbow and speed change (1 and 5):

[Irgendwer]

Rybags, on Sat Dec 25, 2010 7:17 AM, said:

I've found that using luma level 2 on the "colour" lines is perfectly acceptable, even produces better results sometimes.

BTW: Is there any good reason that the black colour doesn't follow the lightness setting? When using a mid lightness setting for the colours the total derivation would be smaller than the popular minimum setting. But thanks to the black exception, the impression is a little bit destroyed then...

[Rybags]

In that mode (GTIA Colour), the COLBAK usage is unique in that it's used to determine the luma for nonzero pixels, but not for the background. The OS sets it to 06 in Graphics 11. (colour 0, luma 6)

It's not normally desirable to have your background the same luma as all the playfield pixels, so you can't get the luma boost on Colour 0.

You can set the background to a different colour, but it gets ORed with the playfield pixels... so any colour other than black will reduce the number of foreground colours you end up with.

[Irgendwer]

Rybags, on Sat Dec 25, 2010 11:29 AM, said:

You can set the background to a different colour, but it gets ORed with the playfield pixels... so any colour other than black will reduce the number of foreground colours you end up with.

Yes, the result is visible in picture one of post #66.
Personally I think this is also some kind of weakness in the design (like the 7 missing colour registers)...

[mikro]

This is freakin' awesome. You should definitely make a news entry at atari.org or similar, I had no idea about this project until today!

[NRV]

Rybags, on Sat Dec 25, 2010 7:17 AM, said:

I've found that using luma level 2 on the "colour" lines is perfectly acceptable, even produces better results sometimes.

I don't know if I understand it correctly, but at least in the emulator, if I change COLBK to 2, I get something like this:



The change is visible when alternating between GTIA 9 and 11 inside the IRQ.. and also it seems the "luma resolution" is lower.. is that the expected result?
I change the color in COLBK in the "attract" mode (don't press any key for some minutes to see it), but that look good.

By the way, I did a fast test mirroring the screen and got this:



I suppose that with some texture planning it could look decent.. and I should say that using it would be a big boost to the frame rate and a great memory saver.

Kaz atarionline.pl, on Sat Dec 25, 2010 10:51 AM, said:

Nelson, amazing piece of software, congratulation!

Thanks for the nice review Kaz

One more "hint" (you can get to the 4th and last level with two keys):