Jump to content
IGNORED

Project-M 2.0


NRV

Recommended Posts

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 :D

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 :)

 

 

NRV, you are crazy..

 

I get that a lot :D

 

 

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.

 

 

$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!

 

 

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 :D.

 

 

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.

 

 

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. :thumbsup: 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 :D

 

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!

  • Like 4
Link to comment
Share on other sites

 

 

Let me add a working enemy and let's see what we can do :D

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! :D

 

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

Link to comment
Share on other sites

...
...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).

Link to comment
Share on other sites

Very, well done!

 

...

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
Link to comment
Share on other sites

looool :D

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 :D

 

here, a little help:

 

post-11240-129322907928_thumb.png

 

 

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).

  • Like 3
Link to comment
Share on other sites

looool :D

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 :D

 

here, a little help:

 

post-11240-129322907928_thumb.png

 

 

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 :)

Link to comment
Share on other sites

 

Yeah.. the Alternate Reality (the city) "way".. I'm still resisting to it icon_smile.gif

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" ;)

Link to comment
Share on other sites

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.

post-7778-129327899026_thumb.png

post-7778-129327900255_thumb.png

Edited by Irgendwer
Link to comment
Share on other sites

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...

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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)...

Link to comment
Share on other sites

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:

 

post-11240-129332075035_thumb.png

 

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:

 

post-11240-129332085221_thumb.png

 

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.

 

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):

 

post-11240-129332078073_thumb.png

  • Like 2
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...