Jump to content
IGNORED

Project-M 2.0


NRV

Recommended Posts

Yes... I'm also for a cartridge version being just a bonus for collectors or 64 KB purists. Let the rest make use of 130XE and modern storage devices or even the ones from era (floppy disks).

But probably we should just let NRV to develop it without too many advises where they're unnecessary ;) I'm just keeping my fingers crossed so we get Wolfenstein 3D on A8, which will be a world class and legendary effort!

Link to comment
Share on other sites

...Do we really have to have worse game just to make Commodore users not complaining it uses more RAM than they have?

I never understood this 'problem'. The C64 has a whole set of newer processors. To get on level, why would 128kB of RAM suddenly become illegal?

 

Anyway, why always comparing to C64 games? Let the 16bit machine SNES be the 'new' opponent ;)

 

...Oops, this shouldn't become another vs. thread :ponder:, nevermind...

 

 

...When supporting enemies, weapons etc. the struggle for resources just begun...

Exactly. I doubt the full version of Project M, including enemies, could work with less than 64kB anyway (of course I mean 64kB of programm storage & RAM workspace).

 

So, why bother with getting the screen RAM more compact?

 

...and, about using PM-gfx for enemies, that would really be a downgrade, as it's 4 col. vs. 256 col.

 

 

 

Anyway, I would like to suggest to the coder to try making different versions:

• P.M. working on 130XE, no other special hardware needed.

• P.M. working on 800XL, executable on cartridge or flashcartridge.

Edited by analmux
Link to comment
Share on other sites

It's up to the programmer to decide game's size.

Obviously smaller memory size is better.

64KB is perfect, 128KB is ok, 320KB will limit user base (however nowadays we have ctirad's external 320KB memory expansion, big cartridges like "Corina" with game save feature and flashcartridges).

Link to comment
Share on other sites

So, why bother with getting the screen RAM more compact?

 

Because you save casting rays for the lower half of the screen?

(CPU time is also a resource.)

 

 

Actuall, NRV did his stuff, the way he thought to do it. And, look how far he has come .

Any discussion of useless stuff only may keep him losing the focus on the origin of the project. So I wished, you guys would never have started posting this obsolete content.

 

No one here would have thought, that version 1.5 could have been changed into a "real game" just as version 2.0 is.

Link to comment
Share on other sites

Wow, I will try to catch up to all comments :)

 

Oh, should have mentioned... you have to change COLBAK to zero again on the luma lines, since we have a similar annoying phenonema in Gr. 9 mode - COLBAK gets ORed with the pixel value.

Doing that will also get rid of that annoying venetian blind effect in the border.

 

That will be a problem then, because it sounds like you need to change COLBK and PRIOR at the same time then.. maybe could sacrifice a player or missile to cover the borders.

 

 

Hmm I see 21 fps on this screenshot, it doesn't look like big boost to frame rate or am I missing something :)? Btw.on the screenshot above this one shows 24 fps with no mirrored texture and larger view area :)

 

It was a fast test, I only changed the display list to mirror the top area :) (the engine is still drawing all the screen, you just don't see the lower half). I will try to do a proper "speed" test later. But about the memory, from what I see I could free at least 4K from the display, like 4K from textures and like 7K from code.

 

 

I think the 'master' ;) just used this metallic texture because the bricks he had don't look good mirrored. But of course you can also make good looking mirrored bricks (attached). BTW: The tiles from 'Yoomp!' are also mirrored and do not ruin the game.

 

What I like to see in this mirrored mode would be the GR. 10 substitution for the GR. 11 lines (with 9 good colour representatives) to inspect the pseudo resolution enhancement and a colour change on the horizon to have ceiling and floor in a different colours.

(I's imaginable to have a second colour change from e.g. green to red, which is moss on the upper half and blood on the lower - just a question of textures...)

As mentioned: colour registers and PMGs will support it. Just think about even the GR. 10 replacement with the 9 colours.

Be strict and take away 4 colours exclusive for PMGs (which can result in 6 colours for them (GRAF-mode) - e.g. 3 skin tones, three for uniforms etc.).

5 colors are left, resulting in total 80 shades (like gray, blue, brown, red and green scale).

Sacrifice one scale to be changed at the horizon and you have the different floor/ceiling colour.

I think that reuse of textures in different colours is also done now, but at the moment you have to remap the values. Applying different scales on various levels is easy when you just have to change the base colour scale register...

 

I might have a wrong impression, but ATM it seems that a single texture tile/wall segment uses a single colour scale anyway. NRV?

 

I will try at some point the use of gr.10, but I don't believe it will look good with the "half a pixel" displacement (but I can be wrong). I was also thinking of using it as a replacement of gr.11 (the color part), with this I could change colors by DLI, change the background color or do some simple color animations on the fly. It can be also used to replace the gr.9 lines, but that will be less useful in my case. Anyway, I don't like the restrictions that this could impose over the P/M colors.

At this point I support the use of textures with columns of different colors, but I'm not using any because they don't look that good.. so probably changing the color at the middle of the screen also wouldn't look good for textures.

 

I think all experimentation is "valuable". I still want to do the best I can in 64K and for now I still have memory, so I don't want to use the mirroring, I like very much how things look right now. But, if someday, the ONLY WAY to have something playable in 64K is using mirroring, I will probably use it (but still wouldn't like it :D, textures will need a lot of work to look good there), or maybe as an option for people who don't mind. In that case I will have also a version that run from cartridge, on all machines with 64k, and a version that runs in a 130XE (for people that don't like cartridges :)). I don't believe I would need more than 128K.

 

 

The idea might work in a "shortcut" type of sense for certain objects like doors where the data could be written to two locations as a column is built, but I imagine that'd create a whole new coding problem with a seperate render routine needed, plus the overhead of working out which one to call for each column of pixels.

 

The idea of having different "render paths" is not that difficult to implement. Could save space for more textures. The problem right now is that the texture code is the section of unrolled code that eats more memory from my "design", so adding this in 64K is impractical.

 

 

Attached PAL/NTSC versions patched for use with Atari800WinPlus emulator only.

So don't tell anyone if it won't work elsewhere. ;)

 

Thanks Miker, they look good:

 

post-11240-129339081962_thumb.png

 

I suppose you changed the display list to add or remove a scanline (the same change I did in PM 1.5 should still work), the only problem is the "hud" effect, but that is a minor detail (also the gold items look a little different, but I suppose that's an Atari800Win "thing).

 

 

Now chose a "standard device" , as used in the 70s already, called "Cartridge" . Just as ROM for storing all textures. So, at the end, all will run on a stock machine.

 

All correct. But just a few thoughts:

+ not everyone likes to have a cartridge (remember that poll?) (and self modifying code on cartridge is hard... ;) )

+ more memory usage means less user range: 128k? 320k? 512k? 1MB?

+ more memory usage doesn't mean better programs (remember that huge karateka demo?)

+ programs which won't work on a stock 130XE are not allowed to participate the ABBUC contest

+ I appreciate 'Space Harrier' but at least now, it doesn't seem to run without cart

+ using much memory for something isn't retro ;) - I could digitize 'Gone with the Wind' to APAC, building a huge ROM. But what does it show?

+ I don't care, but C64 guys will start complaining if leaving their limited 64k view of the A8

+ using our 'co-processor' ANTIC to speed-up visualization or allow other neat things AND additionally save memory IS cool and something other machines can't!

+ remember 'Bomb Jake' and the problem of some users to load big files? The compressed version was very appreciated.

 

I agree with a lot of these points :)

- the cartridge is an "old" standard used a lot in the Ataris and the old game consoles.

- in these days (at least for me), programming in these machines is about the limits.. the possibility to optimize to the very end and see how good you are at getting the best solution (this also applies to the "gameplay" part of the equation..).

- an Atari for me means 800XL and 64K (that was what I knew).

 

Contrary to all the evidence.. I'm not trying to do a port of wolf3d (yeah, I know :D).

I like to create "new" things, so if I can (and get to that point) I will try to do something different AND better :).

Anyway, right now is all speculation. I return to work in one week and probably wouldn't be able to advance at the same speed of the last month (but I will try :P).

 

Regards!

 

 

(some development screens)

 

post-11240-129339826145_thumb.pngpost-11240-129339828461_thumb.pngpost-11240-129339829531_thumb.pngpost-11240-129339830751_thumb.pngpost-11240-129339831685_thumb.pngpost-11240-129339869732_thumb.png

Link to comment
Share on other sites

@NRV:

 

Yeah, the "patch" is based on that used in 1.5 version (simply I made file comparison and changed the DL in similar way as there is) and it was made beacuse many people here and there still use A800WinPLus emu.

 

In fact "hud" looks a bit unclear and that gold items aren't gold anymore in PLus but the game itself looks playable as in Alrirra.

Link to comment
Share on other sites

Raycasting only does the one check per angle, it's "raytracing" that checks all Y values and if it was used the FPS rate wouldn't be 21, it'd be more like .21

 

You are right, but I think you could agree, that you have to access texture memory and copy that to screen (obviously even now with tweaking the texture colour). ;)

Link to comment
Share on other sites

Congratulations!

Now, I have a dilemma what to do with that one thing...

 

Thanks!

I don't know exactly what "that one thing" is, but please continue with it and publish it in the not so far future.

 

 

put the engine into Numen 2... ;)

 

That would be something, but maybe is a little to much to ask :D

 

 

How about trying the "head bob" for the view like modern FPS games has. Shouldn't mean much coding, and could really make it that extra cut above all the other 8-bit 3D stuff.

 

The head bob has been in my wish list for some time. The normal "hack" of moving the whole screen up and down should be easy to implement, maybe just changing a little the display list.

 

The (most) correct way, of moving the point of view up and down, would be impractical for me right now, because my "write texture column" methods are hard coded to write at certain positions (heights) of the screen area. Moving the point of view up or down, basically has the effect of moving up or down the positions of every wall column, but the displacement is bigger if the column is far away.

 

The limit cases are with the point of view at the top of the screen (all wall columns should start at the top then), and with the point of view at the bottom of the screen (all wall columns should end at the bottom).

 

post-11240-129347345401_thumb.pngpost-11240-129347346003_thumb.png

 

post-11240-129347346722_thumb.pngpost-11240-129347347278_thumb.png

Link to comment
Share on other sites

isn't that enough with the given low resolution?

 

Sorry, you mean the pictures?

That's only an example drawn in Paint. Maybe I can hard code a new view point height (different to the current "middle height" one), but my point was that I cannot change between different view points in real time (right now).

If you were talking about changing the display list, I hope so.. :)

 

Regards.

 

 

(About the "night-view" mode in other post.. if for the entire screen and without textures it should be easy to implement, it's just selecting a green color for all screen and using new luma values for the "depth cue" mode).

Link to comment
Share on other sites

Isn't exatly this, where extra LMS lines can help? Put some on top repeating the blue, put some on the bottom , repeating the grey.

 

Now change the count of them

 

Example

 

3 on top - 1 on the bottom

2 on top - 2 on the bottom

1 on top - 3 on the bottom

 

(or even more , if possible)

 

 

Link to comment
Share on other sites

Isn't exatly this, where extra LMS lines can help? Put some on top repeating the blue, put some on the bottom , repeating the grey.

 

Now change the count of them

 

Example

 

3 on top - 1 on the bottom

2 on top - 2 on the bottom

1 on top - 3 on the bottom

 

(or even more , if possible)

 

Yes, that was what I was thinking, but changing the display list through a DL JMP instruction at the start and at the end (pointing to another DL code that jumps back to the normal display list). I cannot just simply add lines at my screen memory because I'm using a double buffer of 4K each, and need them both to be consecutive (they have their lines interleaved also).

Also I have one LMS per scan line, so I can not just change the first one and forget about it :).

Maybe I could use VSCROL in every line, but changing the DL is not that complicated..

 

(ooops.. forgot about the DL JMP black line effect.. cannot do that for the jump back at least.. maybe should have a lot of DL single blank lines and write over them when needed.. VSCROL is looking nicer right now :D)

Link to comment
Share on other sites

Two questions from xxl:

- do the walls must have the same height

- should there be a 90-degree angle only

 

Right now the answer is "yes" to both.

 

But...

 

I think I could have walls of smaller height (not bigger) than the "normal" ones, without too much changes. The problem would be that ,still with that, you wouldn't be able to see through the "top" of the wall. I mean.. assuming a "low" wall goes from the middle of the screen to the bottom, the raycasting right now would stop at the first wall (and the top part will be drawn just "empty"). As a general solution, I could implement "windows", parts of a column that let the raycasting continue (to get "arches" like AR: The Dungeon, for example), but that would be a little more complex and hit the frame rate (in those parts).

 

Right know I'm calculating intersections only for the border of the tiles, because I have precalculated steps and distances for every ray angle, per tile. That's why the "90-degree angle only" and also why I don't have the doors in the "middle" of the tile (like in Wolf3d). Implementing the middle horizontal and vertical lines inside a tile could be possible.. also the diagonals between the corners of a tile.. more than that, like a free angle, will be more like another engine (I haven't thought much about that specific case).

 

I hope he understand what I'm trying to say.. if not he can always ask more questions :D

 

Regards!

Link to comment
Share on other sites

Offical congratulations for doing this in 64k at that speed! I had one more idea which might save CPU (depending on the engine works). Having a (rather) static image of the player or hi/her weapon. As long as is does not change (of course it has to sometimes), this part of the screen would not need refresh. And regarding memory: Especially for softsprites, unrolled code is the best there is, so having a banking card/support ext. RAM would be perfect. Of course a 64k mode (maybe with less details) makes sense too. It'd be similar to the level of details you can choose on any 3D game depending on which GFX card you have. if you want the maximum detail, you need the respective "horse power".

post-17404-129353718421_thumb.png

Link to comment
Share on other sites

That's an idea although I'd suspect 2/3rds or more of the gruntwork is doing the raycasting calculations.

 

Regardless of that, it'd be a touch of polish that puts it another cut above. So much nicer to see the weapon you're equipped with rather than having to glance at some tiny icon or bit of text that's not on the action part of the screen.

 

Of course, that then means we'll want the gun moving as part of the head-bob stuff, and some degree of animation.

Link to comment
Share on other sites

Now that the idea that NRV is using these images because they are readily available for conversion and inspiration, not that he's necessarily going for a conversion of Wolfy is starting to sink in, I wonder what themes does he have in mind? More of a fantasy, a game similar to wolf technically, but in a different setting? His engine can obviously do outside areas, so maybe several smaller buildings? Small towns? ;)...

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