PM 1.5

[GroovyBee]

Could you post an executable? I'm interested in this engine. Would be a great base for Dungeon Master style game.

 

There is a *.xex file in the zip in the first post.

[NRV]

Could you post an executable? I'm interested in this engine. Would be a great base for Dungeon Master style game.

 

regards,

Jakub

 

I assume that you are talking about the pictures, here it is:

 

mazes.zip

 

The 3 executables are almost the same engine, but one for gtia9 (the only one with floor and ceiling), the other for gtia10 and the other for g15.

I can post the sources in some days, because I need to search a little for them, and maybe clean and port them to mads. I had already posted the source to a similar engine in the previous "P.M." thread by the way.

 

These ones are slow (compared to project M), because of the renderer (is not optimized and there is the need to pack 2 or 4 pixels per byte, with LDA-AND-ORA-STA sequences). In project M the renderer writes the full byte all the time. Also there are only 32 rays per screen and the "engine" only need to do additions and subtractions (no multiplies, divisions, square roots, sin or cos functions), with the help of some tables. In other words, the old methods can be optimized to be faster (also, because with those you don't have freedom of movement, only like 8 positions per tile).

 

I underestimated a little the time needed for the raycasting, but I still have some optimizations to do. In very open areas I have seen the frame rate go below 10, so I'm going to try to optimize that case also (at that time I got out of the map, by error, so it was like looking directly at the memory of the computer ). Normally, when you are in a closed area, the renderer do a lot of work and the raycaster very little and in open areas is the other way around, so is kind of balanced.

Edited November 6, 2009 by NRV

[Allas]

It look fantantic. There is a good appearence of deep on those corridors.

Inmediatly I remember Stonekeep PC game.

[Sheddy]

looks fantastic

[tebe]

 

in attachment real DOS file version

PM_1_5 PAL_EXO.zip

Edited November 9, 2009 by tebe

[MEtalGuy66]

Maybe I shouldnt be putting my "two cents" in here, since I am not doing any of the work..

 

But heres my oppinion.. You can take it or leave it:

 

Don't cram the game into 64K if its going to "crappify" the features.

 

90% of anyone who collects Atari 8-bit stuff has at least one machine with extended ram, And those who don't can run it on the emulators.

 

If it was me, and I was already forseeing memory constraints at this point, I would design the game from the ground up with efficient use of banked memory in mind. Save the work of having to implement it later.

[Allas]

128K maybe, but no more....

[MEtalGuy66]

128k sounds reasonable... And if you need it, you could even utilize separate antic/cpu access to extended RAM "130xe style"...

[analmux]

This project really gets interesting more & more every day.

 

I'm still curious how easy it is to add the (software) sprites now.

More RAM needed? More CPU time needed? etc.

 

About memory problems. I could say the same as in the 'Prince of Persia' topic. If you manage to finish this project, it would really be worth it to put it onto cartridge. I don't know how much self-modifying code you (NRV) are using, but especially for large patches of unrolled code, the cartridge might be an excellent solution. There are flashcartridges (from classics) and some other guys should be willing to help you with getting it distributed on custom cartridges. OK, of course many users have memory-expanded A8's, but I think it would be worth it trying to make this stuff available for the standard machines of (minimally) 64 kB. OK, of course the Atari 400/800 series is out of the question, as they lack GTIA modes.

[Rybags]

400/800 shouldn't be a problem (other than lack of RAM)... seems CTIA is much of a rarity that practically nobody here identifies as owning one.

 

The real problem is NTSC, since they don't do PAL hue averaging between scanlines.

 

Sprites, I feel shouldn't be a major hurdle - PMGs work mostly normally in APAC mode, and clipping via Z-buffer shouldn't be too much of an issue.

[NRV]

Thanks for that version Tebe!

 

Don't cram the game into 64K if its going to "crappify" the features.

 

90% of anyone who collects Atari 8-bit stuff has at least one machine with extended ram, And those who don't can run it on the emulators.

Yes, that's a good point. Right now I still need to finish some of the basic functionality of the engine, and that will be same for 64K or 128K, so I don't think that I will need to redo any work yet. Also, I'm already planning the memory distribution to use banked memory, useful when doing a version with a special loader, to run on real machines. I want to know how many features I can put on 64K and then what's the best game I can do (in 128K). One of the modern cartridges could be also an option.

 

I'm still curious how easy it is to add the (software) sprites now.

More RAM needed? More CPU time needed? etc.

Well, something like the barrels of the previous demo have a "medium" cost in memory and cpu time.. I wouldn't like to have more than one on screen in the current state of the demo. But for the next step I will try to use the P/M's to do one enemy, with some frames of animation and scaling. In that way you don't need to mask the graphics when drawing to the screen, and don't need to have pre-shifted frames in memory (well, in the GTIA case you only need 2 pre-shifted frames.. or just one, if you can live with the coarse movement).

 

The real problem is NTSC, since they don't do PAL hue averaging between scanlines.

I still haven't seen the demos in a real NTSC so I'm curious to know about that.. maybe now that there is fixed version "someone" (cough Allas cough) could film this?

[Shawn Jefferson]

I second the flashcart route... Atarimax sells flash cartridges in 128k and 1024k sizes, 8k banked in at $A000 and able to be turned off.

[miker]

Yeah! Can't wait to "walk" over these mazes!

 

I've noticed that when walls are father from the "player" (or rather camera) the redrawing of them gets more noticeable, so maybe try avoid "large halls" in mazes.

 

But nevertheless - great work!

[analmux]

...so maybe try avoid "large halls" in mazes...

Or, maybe another suggestion:

 

Maybe only some passive pick-up objects or no objects in large halls. And, one or even two enemies (at a time) in the narrow corridors. This might spread out the CPU need a bit.

[Allas]

A real NTSC 130XE playing Project M

 

http://www.4shared.com/file/150501469/4b80fb1f/pm15_realntsc.html

 

Well, it seems very near to the emulator. There are some differences on the colors because of NTSC palette. I'm not sure if the screen represents 128 or 256 colors. However, who cares? it looks great.

Edited November 12, 2009 by Allas

[Rybags]

That doesn't look too bad.

 

Is that from a camera, or capture card?

[Allas]

That doesn't look too bad.

 

Is that from a camera, or capture card?

 

from camera, it looks better than video shows.

[Allas]

Some shots could be useful to examine how this program works on NTSC.

[Rybags]

It looks the same as PAL.

 

Maybe it's your TV? I don't know since I've not seen APAC on NTSC.

 

Brazil uses PAL-M (525 lines x 60 fields) which is unique to them, so maybe a lot of TVs built for South America can handle multiple standards... ie - your TV might act slightly differently towards APAC than e.g. a typical US destined TV.

 

One of these days... I'll author a quick/dirty NTSC DVD with an APAC style picture to see if I can replicate what's supposed to happen on my TV (which can handle both PAL/NTSC).

[Allas]

Actually I don't understand what is supossed to be the technical difference on APAC mode between NTSC and PAL.

I read on some place on the forum NTSC could not do the APAC mode, but I always had seen the APAC mode on any TV.

[potatohead]

The overall effect is mostly the same to my eyes, in that I "see" more colors than I would expect to see. The NTSC is the lesser quality display however.

 

The difference seems to be where PAL displays will actually display "new" colors with this mode, as in the pixel color isn't one you can just select from the Atari palette. Mixing of colors actually occurs at the display.

 

The NTSC display only contains pixels with colors that are in the Atari palette. Our mind "sees" more colors because of their proximity, but no "new" colors are actually displayed on the screen. IMHO, the mixing occurs largely in the brain, not the display.

Edited November 12, 2009 by potatohead

[MEtalGuy66]

The way I understand it, APAC alternates hue(mode 11) and luminance(mode 9) every other scan line.. The PAL displays tend to allow the chroma & luma to "bleed" or average more between scan-lines..

 

I dont remember this from back in the day.. Maybe my NTSC display was alot crappier than most, but it seemed to "bleed" just fine for me..

 

Another thing i remember is that there was also an "Interlaced APAC" mode where every other scan, the luma/chroma scheme was reversed.. This offered twice the vertical resolution (but also obviosuly uses twice as much memory).. Since there are only 2 "scan phases," the flicker was barely noticable on NTSC.. And since every single scan line was used for both hue and luminance, you get a better "mixing effect" on sharper displays..

 

For your pusposes, however, it srikes me that there is a third variation of this mode possible.. Let's say we werent willing to sacrifice any more memory.. and also that we didnt really need more vertical resolution (I dont think we do).. You could implement interlaced APAC so that it uses the same memory and vertical resolution as normal APAC.. just swap each hue scanline with its luminance scanline "partner" every other scan.. Youd end up with the same vertical resolution, better color mixing, and less "pronunced scanline" looking effects.. and the only additional memory you use would be the extra display list, and VBI/DLI code..

Edited November 12, 2009 by MEtalGuy66

[NRV]

A real NTSC 130XE playing Project M..

 

Well, it seems very near to the emulator. There are some differences on the colors because of NTSC palette.

 

Great work Allas! is nice to know that NTSC looks like that.. I like the bob up and down effect.. I should put it in the next demo

 

 

You could implement interlaced APAC so that it uses the same memory and vertical resolution as normal APAC.. just swap each hue scanline with its luminance scanline "partner" every other scan.. Youd end up with the same vertical resolution, better color mixing, and less "pronunced scanline" looking effects.. and the only additional memory you use would be the extra display list, and VBI/DLI code..

 

I will try this in the future to see how it looks

[Rybags]

I've done the line-swapping technique before... it gives a fuller look but you get flickering, although it would probably be less prominent on NTSC.

 

APAC on PAL... the "weakness from the strength" of PAL is that it tends not to get hue shift error due to the inversion of the colour carrier per scanline. The weakness part is that you have reduced colour resolution in the vertical because each line is averaged with the one before it.

 

Of course that becomes a kind of advantage because it allows APAC to work. But the new colour you get is desaturated, so APAC colours don't actually match what you'd expect. The colour only lines, they're visible but adjacent to brighter colours are barely noticable.

[R4ngerM4n]

Any news?