the maxcoderz thread has been updated as well
[link]


i think that, given the complexity of the walls already along with the addition of scaled sprites, things will be hectic enough. dithering on the walls would probably just make it harder to tell what's going on(unless it was done in gray, and that just isn't happening...).

anyways, this is wonderful, ben! even if it doesn't go anywhere else, i am already incredibly impressed!

Thank you for all your kind comments!

I've written a fairly rough description of how I'm handling occlusion (clipping of geometry so you can't see through walls) and how that has been expanded to support sprites in my latest post. There is a new demo which uses a larger two-room map - the 6MHz TI-83 and TI-83+ struggle with it a bit, I'm afraid, so for those with more advanced calculators don't forget to hit Zoom to switch to 15MHz (I hope to get it running fairly smoothly on a 6MHz calculator as that's all I own myself).

I did try dither-filled walls, and unfortunately ran into a bit of a snag. Here's a photo of my calculator with the contrast at its maximum setting:



The LCD hardware is not a fan of dithered patterns, evidently. Solid fills should be possible (and quite fast). If I can figure out the perspective projection then "wall aligned sprites" (in Build engine parlance) may be a decent half-way-house between the current look and full texturing. This would be the ability to attach a sprite to a wall and have it look like it was stuck on (so it wouldn't turn to face the viewer like other sprites), and would be handy for buttons/switches as well as other decorations.

Ooooh, I remember running into some of those same LCD problems deep in the dark past of my BASIC programming days. Too bad grayscale is such a big overhead; this would look very sleek with grayscale, I think, and it would be trivial to make the gray level change based on the viewer's angle to the wall, like a reflectivity effect.

Wait, maxcoderz exists again?

Yeah this is a 83+ specific issue. It happens on the 83+SE, 84+, 84+SE and TI-Nspire as well, but much less bad. Quite annoying when working on 3 level grayscale games :/. It's even worse when filling the screen with horizontal lines.

It still looks good, though.
Yeah it's still alive, it seems. However they felt behind in activity in the past year or two. X.x

I posted a topic about Doors CS 7 on there, and after two weeks I think it only had views from me, and no replies.

MaxCoderz is very popular with spammers, though. I sign in quite frequently to delete their accounts, but other than that there is very little activity. Still, it was originally a MaxCoderz project so I thought I'd post it there first to see if it tempted anyone out of the woodwork!

hey, i replied

So you did, sorry for forgetting; DShiznit, you did too.

But we're getting off-topic. Who has more Nostromo-centric things to discuss?

I like the current wireframe look, but how well is that going to compliment sprites?

like i said, i think it will compliment them rather well if they are the only complex things being displayed on the screen as it will make them stand out better, which was always a bit of a problem with other calc FPS's i've seen. only time(and more hard work from benryves, of course) will tell.

Definitely agreed, and if they look too out of place, it's the work of some simple sprite editing to make them fit into the "wireframy look" more naturally.

This looks amazing Benryves!

I actually like the walls defined with just lines on a limited resolution calc LCDc-- it actually looks really good. And the fact that you were able to implement stairs as well as looking up and down at those frame rates is really impressive!

Thank you again for the comments.

The main issue with the outlined look is how to make the purpose of structures within a level obvious. In DOOM you can tell if a "wall" is a door, lift, switch or other special feature by its texture. I suppose there are other ways to make these features more obvious - the crosshair changing into a hand when looking at something interactive or a sprite near the thing as a sign, say.

Looking up or down is done in the style of Heretic or Duke Nukem 3D ("y shearing") - all it's doing is shifting the viewport up or down in 2D. The further you look up or down the more distorted walls appear (you'd never be able to look straight up or down, for example) but it's better than nothing.

I haven't had any more time to work on the project recently but did have a shufti at the inner workings of DOOM for "inspiration". One trick I had missed is to store the angle of each wall in the level data. This allows you to very quickly perform rough backface culling, as you can compare the wall's angle with the current view angle to determine whether it's facing away from you entirely or not (I currently clip and project each wall in turn to determine which side you're on). Due to perspective projection I don't think this will be completely reliable (a wall that is perpendicular to the projection plane would show one side if it was on the left of the screen and the other side if it was on the right of the screen, yet still has the same angle) but it may be a way to quickly discard walls that more obviously have their backs turned to you.

Another trick is to store a bounding box for each node of the BSP tree. If this bounding box is outside the field of view then that node and all of its children can be ignored.

As with all potential optimisations you do of course have to ensure that these additional tests (such as the bounding box for BSP tree nodes) don't take longer to perform than the chunks of code they're attempting to avoid having to run. In some instances they may make simple levels run slower but make larger levels run much faster, so it'll be interesting to see what happens...

By the way I looked at the new screenshots on MaxCoderz and I was shocked. Even if this ends up being for the SE/84+ (which most people own nowadays) it will still be amazing.

Thank you! calc84maniac pointed out a bug which would scramble the display on 15MHz calculators, which I think I've fixed. I have also enlarged the level somewhat. I've tried to optimise it as best as I can but the framerate drops considerably when viewing the central room with the pit due to the number of subsectors and lines being handled. The rest of the level seems to be unaffected by the new rooms added to the level, so it seems that the rendering engine scales relatively well (silly statistics: 106 vertices, 139 walls, 52 convex subsectors, 23 sectors, 103 BSP nodes).

        

        

The latest version of the demo can be downloaded here and there is also an animated screenshot.

I saw this on your Facebook a few minutes ago; you continue to amaze me. Even aside from the amazing 3D rendering engine, you even take the care to implement sliding doors/walls just for fun.

Heh, thank you; all that's doing is modifying the floor height of two sectors. When (if) I get around to implementing better movement physics (with collision detection) I'd like to also add other effects that can easily be achieved by changing the floor and ceiling heights of sectors, such as lifts, crushing ceilings and rising stairs.

Oh wow, the idea of rising stairs makes me wonder just how hard some simple portal mechanics would be to implement. The only (well no, one of probably many, many) problem would be making enough sprites to fake portals on walls angled with respect to the viewer. No matter where you end up taking this, though, it has huge potential.