nathanielbabiak 2022-11-07 07:05 (Edited)
The LRNX display system is finalized at this point.
You can inspect the levels in the GFX background editor. (Start with the tech demo, it's easier to learn from. It also includes cursed doors.) The static dataset format is completely done, and reflected in both levels. There's a bunch of rules to follow, shown as comments at the bottom of the source code.
Working with the engine is relatively painless, as you can see from the code within SUB MAIN. It calls subprograms prefixed with RX and PXL_, these are intended to be used by others to create their own 3D games.
nathanielbabiak 2022-11-07 07:22 (Edited)
There’s a projection error in here, I’ll revise tomorrow.
[Edit: There's no projection issue, it just looks really rough since it's low resolution.]
nathanielbabiak 2022-11-07 12:57 (Edited)
Forgot to mention this upload is just a follow up to this post.
I wanted to strip away all the hard stuff so it’s easier to see the ray casting code. (No movement clipping, no textures, no display system, no doors.)
was8bit 2022-11-07 13:28
Its actually wonderful :)
I could actually use this format for my game if I restricted movement from centerpoint to centerpoint, and cardinal directions... and allowing a smooth transition movement in between the points... only because the game i want to emulate is an old intellision dnd treasure of tarmin..
nathanielbabiak 2022-11-07 15:26
That’d be great - you should totally do it!
1992’s Ultima Underworld did something like that, it worked really well.
I’d recommend we modify this code to give you some space to work with - otherwise there’s no room for a HUD. Let me know how many 8x8 pixel cells you need at the top, bottom, left, and right for a HUD, and I’ll set it up.
was8bit 2022-11-07 16:21 (Edited)
Video of actual game...
https://www.youtube.com/watch?v=ZqhCM5Ntllo
My test version...
https://lowresnx.inutilis.com/topic.php?id=95
To test my attempt at 3d enemies, there is one hiding in the corner right beside your starting space... you have to go forward abit, and hang a hard right and go back to the inside of that corner, he's hiding there ;)
I have already experimented with pixelated animation of characters here...
https://lowresnx.inutilis.com/topic.php?id=2409
So i may overlay that, since in this game one will only encounter enemies one at a time...
I am flexible on precise amounts of space, as long as there is space on the bottom... the closeup spot in the bottom center (things at your feet you can pick up) is something i can draw to manually, so i reckon i will just need the bottom 4 rows free...
... so a 3d window of cells 0,0 to 19,11 with cells 0,12 to 19,15 left for my user interface...
Hey, i might realize my dream of getting a rebuild of this game afterall :D
was8bit 2022-11-07 16:23
... the current colors are just fine :)
nathanielbabiak 2022-11-08 04:50 (Edited)
was8bit, I see what you're going for. The latest upload is a good start towards that. Feel free to take it and remix it (as with all uploads). I'll keep working on a sprite driver to put objects and enemies in the maze.
For the HUD, note the display driver causes the cell coordinate CY values at the bottom of the screen to be a bit different than normal. Check out SUB D_HUD for info.
Also, I took out all the code that avoids crashing, so don't go running off the map!
was8bit 2022-11-08 14:25 (Edited)
Cool beans, hot digity, awesome possum!!
was8bit 2022-11-08 15:46 (Edited)
Hmmm... as i work thru your code, i see some differences ...
My system uses a cell approach, movement is from cell to cell, with possibly a paper thin wall between two cells...
Your system seems to also be cells, but each cell is either empty or a filled as a solid block...
... so, i've upped your map size to 37x37 and it seems to work fine :) i will have to modify my maze to work with this system...
... i am now trying to restrict turning to cardinal facings, +-90deg at a time..
... then i will want only forward movement, auto scrolling from block center to next block center..
... this emulates the movements in treasures of tarmin...
Your code is very easy to read, so i should be able to get these, once i track the math :)
nathanielbabiak 2022-11-08 19:20 (Edited)
I get what you mean about cells with paper-thin walls vs solid-fill… But when you say 37x37… I presume my cells become the paper-thin walls, but how big are the rooms within the walls? Can you upload a sample 37x37 map that shows this? (I’m asking because I have some ideas here to help, it’ll be easier to show than explain though.)
Also, do you want me to write a different movement SUB, one that sets the camera position and rotation (rather than incrementing/decrementing from the previous state)?
nathanielbabiak 2022-11-09 05:00 (Edited)
"Paper-thin wall" settings are in M_INIT for you to play with. Movement can be "set" (rather than incrementing) using M_CALC_SET.
Billboards (i.e., 3D objects) are almost projected into the 3D space correctly. The tree kind'a works, but not quite. (Hiding billboards so they appear around corners is trivial, but I need time to write it up.)
Scaling BMPs - essential for billboards - will have to wait. I want to use the one-sprite-per-pixel approach, but I don't want the size of each pixel jumping around. I've got an algorithm figured out, I just don't have enough time to write it up.
I added the BMP subprograms too. They'll be necessary to scale the BMPs. Since the subprograms are already in there, the ray cast map is now a BMP, it's in M_INIT and character page 2 of the GFX Designer.
Check it out, let me know if you have any questions!
More to come... :-)
was8bit 2022-11-09 05:25
I would prefer paper-thin walls as that is how the orginal game is set up... the layout is 12x12 with an outer hallway that goes all around the edge, and the inner 10x10 contains the actual Maze... which actually I have the original layout concepts for their Maze formation and it actually contains a randomly chosen set of possible premade portions ... which I will want my version to do as well... so while exploring their is familiarity of what variations to expect so you won't get too lost and can anticipate abit as you navigate the inner maze...
was8bit 2022-11-09 05:27 (Edited)
each cell occupies one thing... they are small, almost cavern like... just abit bigger than an office cubical but smaller than a standard sized room...
... the walls would exist where 2 cells edges touch, each cell theoretically may have 4 walls all around it, with one or more walls having a door or a gateway in a wall...
A door is a door that you can see.. a gateway is a secret door that may be a regular door, a magical enemy, or a passageway to another map...
was8bit 2022-11-09 05:39 (Edited)
Plain colored walls that change colors so as to see the 3D is great, like you have them now...
I would need to restrict player movement from center of a cell to another center of a cell... movement can jump as the original game did, or they can move smoothly, which would be better maybe... forward only though but that part is easy ;)
Turning needs to be restricted to +- 90deg and jumping to that direction is fine as that's how the original works, and often you need to glance left and right quickly to see if there is a nearby enemy you need to worry about...
I tried getting the turning restricted but was only 99% successful and repeated turnings on one direction started getting the directions abit off... 90Deg then 89deg then 87deg etc...
I was trying to work on limiting the forward movement but had to leave for work ;)
was8bit 2022-11-09 05:40
My limited movements should greatly simplify some of the math, it's abit cumbersome trying to backtrack your finely tuned movement into more generic movement...
was8bit 2022-11-09 05:46
If you have abit of time, try watching the link to the real game, focusing on the 3D portion, as I will streamline their overall side map into a single shaft downward... by watching the original gameplay you will see why so many people still to this day still enjoy playing the original game, even with its severe limitations... the gameplay is addictive... you feel like you are actually exploring an unknown territory and you never know what to expect around each corner ;)
was8bit 2022-11-09 05:46
Bigger open spaces exist in the original game, but they are rare...
was8bit 2022-11-09 05:55 (Edited)
Another thought... things after a certain distance are rendered as black empty spaces, usually at the center of the screen... things that can be seen but are at a distance can only be seen... you cannot interact with them nor can they interact with you... doors, items, enemies, must be in a cell that is directly in front of you ... then and only then can you and whatever interact with each other..
was8bit 2022-11-09 06:07
There are 20 enemies, each with 2 images... one bigger image when it is in front of you, and a smaller image when it is 2 cells away from you
All of the items are of one size, so in original game it is abit odd that they stay the same size as they get closer to you... there are 44 different items...
The original controller has 16 different commands you can use in addition to the circle pad which offers direction control... I just realized that the game also offers a RETREAT command as well as a LOOK LEFT, LOOK RIGHT commands...
was8bit 2022-11-09 06:09
I actually played the original at its hardest level and only won once... as it doesn't have a save feature it took me 2 days straight to beat the game!
nathanielbabiak 2022-11-12 08:01 (Edited)
I watched that video, it seems like a very early Roguelike set in a pseudo-3d world. It's super cool!
Today's upload uses paper-thin walls the way you asked. For the walls in this upload, you'll have to create a background in the Gfx Designer, it's got an example in ROM(3) to peek at. In the Gfx Designer for backgrounds, you'll see a "double-wall" visual - that's mandatory. It's how I addressed your comment "each cell is either empty or a filled as a solid block". In the paper-thin version, each cell is defined as having a number of walls, and the renderer checks the cell from inside to outside to find any walls to show on-screen. In the old version, it would've checked neighboring cells from outside to inside.
This upload also has code for objects too. It's pretty close to the algorithm I wanted, but I traded some speed for accuracy. (Check out the "U" of pixels in the tree, the transparent gap isn't always square. This would cost around 3% CPU to address, it's not worth it.) I also pulled in your monster graphic from your test version! :-)
I'll put together a state-based model for the restricted movement next.
I also noticed a few things, not sure how to address them yet, but I'm thinking about it...
More to come...
Dan 2022-11-12 10:05
btw, you can go through the walls, and if you continue, there will be an error
index out of bounds
was8bit 2022-11-12 12:10 (Edited)
So cooll :D
In turning left or right, a "jump" to that direction is fine, a smooth pan isnt needed... the peek left/right buttons of the original game is used often, and simulates a quick hurried glance just make used there isnt an enemy nearby...
The original game doesnt include a top view of the maze, but mine does... its was also a good quick way to check my maze database
was8bit 2022-11-12 12:13
Btw, the item scrolling is super :)
nathanielbabiak 2022-11-13 07:56 (Edited)
This upload is nearly complete! I watched the video again of 1983's Treasure of Tarmin to set the field-of-view, 3D-box aspect ratio, and camera placement within 3D boxes. So the 3D rendering should be pretty much the same as the original game at this point.
This upload includes restricted movement, but the code is in pretty rough shape - it's not exactly a state-based model at the moment.
It also includes rotation (turning the camera) and translation (moving the camera) having different speeds. You can set the number of renderings for a full 90° turn and a full 3D-box of movement within M_INIT, it's the variables M_TRNS (TRaNslation frameS) and M_ROTS (ROTation frameS).
And, I've added a rotating map to the HUD. (It needs optimized for speed rather desperately, it uses so much CPU on it's own.) By not providing a complete map, there's still an element of "maze feel", but providing a partial map makes navigation a bit easier. Not sure this will be in was8bit's final version though, it's not necessary and kind'a flashy. (And it's not pixel-perfect, there's some pretty ugly code to barely fix it.)
And Dan, I added a super-simple clipping algorithm to keep this from crashing. The next upload will clip inner walls too (rather than just the outermost walls).
I'll also do some clean-up to make the code a bit more presentable. (The main subprogram is way too long!)
So, was8bit... at this point is there anything else you want me to add before I pass this off for your additions? Other than what I've mentioned in this post? I assume you can put together the game's flow and assets, yes? And I'll support the renderer?
nathanielbabiak 2022-11-13 08:16
Doors! Like in the video… duh
was8bit 2022-11-13 14:24 (Edited)
It's so beautiful!!! It works so perfectly :)
Yes, doors are essential, but not all doors behave identically.. there are different doors... most will be standard doors that open on command (you can use Bbutton) when they are directly in front of you, and auto close if you make any movement inc going thru them... the doors should not auto open... there will be many times you DON'T want to open a door...
Magic doors behave like an emeny, (will not open, but will attack) and must be defeated... once defeated they behave like a normal door... so maybe a door status... or rather, door magic level....
it might be easiest to make all doors magical, and just set most doors to their defeated state (magic level 0) and then they will start out as standard doors...
was8bit 2022-11-13 14:36 (Edited)
A thought... the circle thingy is meant to show you where the outer hallway is connecting to the inner maze...
Currently it is floating in mid air, which is fine ... original has it behave like an item that cannot be picked up... but either way it can only be seen while in the outer hallway... it also needs to be seen from the inner maze.. maybe as an item it would function that way..
Another thought.. is it possible to have the super cool overview on a temporary basis... say toggles on or off with the PAUSE button... it will be needed but the space it uses is also needed for player stats... being there is fine as long as I have space to use NUMBER commands to replace the stats when the overview toggles off..
... in real life, you only use your map if you feel really lost, otherwise it's in your pocket and your too busy looking around corners, etc.. ;)
was8bit 2022-11-13 14:38
And yes, I have a complete set of all the original graphics .. I can add them in no problem (btw the test monster I have here is just one i whipped up, and not an original)
was8bit 2022-11-13 14:40 (Edited)
I can also fill in the HUD area as well... the maze part was my Achilles heel!!
... I still want your cool overview ;)
nathanielbabiak 2022-11-13 14:51 (Edited)
LOL the “circle thingy”!!! I was just trying to test 3D projections…
This upload has 3 objects in it. I intended to demonstrate that objects could be projected into the 3D maze at ground-level, mid-level, and ceiling-level. These three demonstrations are the monster, tree, and an electric light fixture. (The point was to show that ground-level projections scale from ground upwards, that mid-level projections scale centered, and ceiling-level projections scale from ceiling downwards.)
was8bit 2022-11-13 14:56 (Edited)
Just a note about the video... the original controller had TONS of buttons you can press... each time you here a clicky chirp, a button was press... when you hear a buzz, you pressed a button that was in error (could not currently be used)
Where LowRes has 2 buttons, The original controller has 16.. https://www.mobygames.com/game/intellivision/advanced-dungeons-dragons-treasure-of-tarmin-cartridge/overlays/overlay,114/
So I will have to be clever with my 2 buttons ;)
was8bit 2022-11-13 14:59
Ah.... cool on the different heights... :)
nathanielbabiak 2022-11-13 15:06 (Edited)
The original 1983 game was pretty limited, regarding number and size of sprites. LowRes NX actually has way more power. This has two effects I can see off the top of my head:
was8bit 2022-11-13 15:15
... the diagonal view is fine, in that you can still tell that it isn't in front of you... it's rather more realistic ;)
I'm thinking that everything will be floor based...
And yes, you can quickly see in the original game they had to compromise simulated 3D effects to make room for the tons of enemies and items the game requires... they even had to use same graphics with different colors to up the number of different things...
was8bit 2022-11-13 15:17 (Edited)
Wouldn't using the circle thingy as an item work ok??
When i first played the original game (I rarely read instructions) I was wondering why I could not pick up the circle thingy off the floor ;)
nathanielbabiak 2022-11-14 06:06 (Edited)
Yep, the circle thingy would work great as an item.
Today's upload:
SUB MAIN) and frame animation code (SUB M_TURN and SUB M_WALK)PALETTES)I read a bit about the gameplay and maps. It really is a maze game (partly, at least). I don't think including a picture of the map in the HUD is a great idea anymore. So, I'm not prioritizing any revisions to the map code (it's slow, but it works). Maybe a size=2 map is appropriate (rather than size=3)? At that smaller size, it'd use only 45% of the CPU to render.
The last thing is doors. But...
I'm having trouble developing a clean/simple way to add data to each room of the map. Because the map is encoded as a background in the Gfx editor, it uses one cell per "room of the map". And, because of the "paper-thin" walls, each cell already encodes the "paper-thin" wall state. I see a few approaches:
I started a half-baked idea to address this, it's in the Gfx background editor. The left-most map is the actual one used in-game, but the rest is an idea for another way to store data. It's got the original 16 maps in there now.
There's a second half-baked idea, based on the actual map used in-game. I used the Gfx background "stamp" tool to duplicate the map (it's in the lower right of the background editor), and replaced every wall that needs a door... with a door. Problem is, it would delete any data in that cell about walls, so you'd only see door information in the duplicated map.
I know some games (Mario comes to mind) actually store items in an list of XY coordinates...
These approaches are a bit cumbersome. What do you think, was8bit?
nathanielbabiak 2022-11-14 11:44
Just realized the HUD map is missing a line… That’s a much easier fix than figuring out a data format at least
was8bit 2022-11-14 15:59 (Edited)
You might like this...
https://forums.atariage.com/topic/326033-treasure-of-tarmin-dungeon-maps/
As annexample, i added doors to my map... i use a pseudo maze creation, each cell recording only what wall or space or door above and to the right.... to find out whats on the right, you have to read the cell to the right...
was8bit 2022-11-14 16:02 (Edited)
The idea is that i have the maze shell, and each level will be randomly created... i know the original has set maps, but i rather like a random element to keep each gameplay fresh ... i will stay true to the overall concept ...
was8bit 2022-11-14 16:03
.. not sure what will work best with your system...
McPepic 2022-11-14 16:36
@nathanielbabiak, I love how smooth the movement is! It feels really good to play.
G-9 2022-11-14 17:16
epic
was8bit 2022-11-14 18:32
Also, I LOVE your latest update... the 3D is super smooth :D
was8bit 2022-11-14 23:02 (Edited)
For items and enemies, an array would be fine, as there can only be one “thing” in a cell at a time... this would include the circle marker, the ladder, and even the warp gates in the outer hall...
Also, enemies are stationary, they don’t move...
nathanielbabiak 2022-11-15 00:10
That sounds good - I think I've got enough to go on... I've got a format figured out where you'll be able to modify the map super easy. I'll have a new data format soon that incorporates all this. It'll be super simple to edit in either the Gfx background designer, or in an array at run-time.
And thanks everybody, I appreciate the complements! :-)
was8bit 2022-11-15 03:55
So cool.... i cant thank u enough \(^_^)/
nathanielbabiak 2022-11-15 05:45 (Edited)
[Edit: additions and deletions represent the newest engine]
Hey I'm actually pretty happy with this too. You have no idea how much I want to help make a game rather than a tech demo! All your comments have been really helpful to finally get one of these demos focused into something actually fun/functional.
But, I won't be able to share a progress upload tonight. I'm rewriting everything now that we're getting close-to-done. Here's a change log of what's happening. (I'm writing it out partly so you can begin digesting now, and partly so I don't forget anything!)
The engine will process a static dataset. It will render the camera (and handle movement) based on this static dataset. For now, the static data will come from the Gfx background designer and be loaded into a plain 2D array. Once you review the array format, you can modify it at runtime and the engine will auto-render the updates, since it won't care about modifications, it'll just represent them on-screen.
There's so many consequences of this:
The dataset will include integer identifiers (IDs) for "paper-thin" walls, walkable spaces, and closed or open doors. (The numeric value of these IDs might change through new versions of the renderer, it allows me to make use of binary masks.)
The dataset will include float IDs for partly-open doors. The integer portion of the float will be the same as a closed-door ID. The fractional portion will represent the fraction a door is open, ranging from +0.01 to +0.99. If a door is fully closed it'd be at ID+0.00, if fully open it'd be at ID+0.99. Don't ever set a a door to ID+1.00, because that won't be the door's ID anymore, it'll be a different ID of the next integer. The engine will handle moving doors for you.
Doors render as a special type of wall. The portion of doors between the bars will render transparent - beyond the door, through the bars of the door, you'll partly see the room's walls, and any billboards.
The dataset will include the billboards, specified per "maze cell", and billboards must be centered (they can't be rendered part way between "maze cells"). The engine will determine which billboards to display on-screen. I'm reworking the billboard display system so you can have multiple billboards on-screen at once. So you could have many nearby "maze cells", each with its own billboard, and all would be shown within the same rendered frame, at the same time, in the correct draw order, etc.
Palette management is going to be weird, kind'a hacked together until we get some ideas going. There aren't many palettes to work with for coloring things. But, after the run-time palette handling of this, I'm sure I can handle any scheme you want, but we should probably keep it easy to start:
Right now, walls take up 2 palettes Should this be just 1? The floor/fog takes up 1. Should this be eliminated? Doors don't have any special palette, but I'm thinking there should be a dedicated 1. All billboards would share the remaining palettes.
I don't have any plan yet for the changing colors of cursed doors, but it definitely needs encoded in the static dataset. So you could change the color, make it flash, etc., and the render will just push it out.
Other stuff...
The map needs to be smaller, size=2, to run faster. It also needs optimized for speed. All speed optimizations will make the movement "faster", and once it gets too fast, we'll increase the number-of-frames-per-movement. This will make rendering smoother.
"Billboards" will represent all 3d-projected objects/enemies/etc, and must be in $8000 Character data (using COPY from ROM to RAM won't help), and billboards must be either 1 character or 2 characters. For 2-character billboards, all need to be either 2x1 or 1x2, we can't have both options. I'm thinking they should be tall, rather than wide, to be enemies? they can be either tall or wide. This only effects resolution (it doesn't effect "size" on-screen, as billboards can be scaled. See SUB B_SHOW for scale, the next upload will have an argument RSCALE.)
How many 1-character billboards will there be? How many 2-character billboards? We need double those numbers for use in RAM character data. (Ex, if you've got 16 2-character billboards, I'll use 32 of the available display chars.) They'll need arranged into 4x4 character groups in the Gfx character designer. How many characters does your HUD need? What about other aspects of the game interface? We're going to run short of characters, although you might find a few font characters that can be re-purposed.
All that said - are you reviewing/using the code yet? Any questions so far? Any preview uploads to share?
nathanielbabiak 2022-11-15 06:17 (Edited)
Also, just wanted to mention that this topic has really allowed me focus on billboards, and this stuff can easily be added into other wolf3D uploads with minimal changes.
And, I've got the some improvements for my 3D textured renderer, hinted here. I had actually just conceived of a faster texturized display algorithm pretty recently - it's faster than ever before, but this billboard stuff should happen first.
Finally, I had mentioned needing to pick between textures that were high-resolution vector-based, and low-resolution raster-based. But since then, I've figured out a faster way to do it vector-based (which is already the faster of the two), and this saves enough CPU that I can do both, depending on which is needed.
I'm hoping it's finally fast enough and good enough that I stop obsessing over it, and start making an actual game of my own.
More to come...
was8bit 2022-11-15 10:14 (Edited)
By "billboards" you mean like monsters and items??
Here is a complete list of actual images used in the original game...
https://www.zebeth.ca/playplanet/index.html
(Ignore their map screens, i wont be using this approach, just a single shaft down, and side shifts will just be a new random map)
notice how each one enemy usually has two images as they simulated near and far... this can be reduced to just the one near image...
... also, there are usually the same set of 3 colors for spiritual and another set of 3 colors for regular items/enemies...
each item/enemy is all completely one color, which is fine.. however when there will be different items/enemies in view, and the different carried items will all be seen together in the HUD area at the same time... this would mean all 6 different colors seen at one time...
... this may be a problem...
The coloration of the walls can be kept to a bare minimum... just enough to aid in the 3d depth perception...
All items/enemies can be kept to one color per item/enemy, just like the original...
Speed... lightning fast isn't a top priority here... if something has to be compromised abit, i would rather have abit better visual with abit slower speed, and not abit better speed but abit worse visual...
...If you remember in the video, there are lots of time spend NOT moving forward... glancing left or right to see whats what... thinking about what to do next... counting things (see image of gamepad)... picking up items, rearranging the items you have, putting items back down, rearanging items into different hands... maybe taking a peek at the map...
... then you take a single step forward... ;)
... since nothing in the maze actually moves, just you moves, this isn't a race, more like chess match... for example, you may decide that you are not strong enough to take on a particular enemy... so maybe you decide you need to find a way around the enemy by exploring a different path thru the maze...
you can walk over items, you cannot pass thru an enemy... an enemy BLOCKS your path... you must try to defeat it, or go a different way...
was8bit 2022-11-15 10:34 (Edited)
I've went thru your code, back when i was trying to edit it to limit the movement... was almost successful with that ;)
I will have to add code to show the stats on the right, on the left the items in your "bag", and in the middle what you are holding in your left/right hands...
... and may have to show the current command ... maybe use (b) to change the command, and (a) to do the chosen command... not sure yet...
was8bit 2022-11-15 10:39
A final note... the few horizontally drawn images can be reworked into vertical images... not a problem there... all enemies seem to be 2 cells high, and all items 1 cell only...
nathanielbabiak 2022-11-16 03:09
Sorry, wasn't clear earlier - a "billboard" is a raster/bitmap sprite projected into 3D space, and billboards are always face the camera. (They can't rotate like the walls, so it can't face "away" from the camera, and the camera can't sneak up on a billboard "from the side").
But... that link you gave has a *lot* of billboards. I'm thinking about how to accommodate... The game engine must be able to display *many* billboards simultaneously, but the system I had developed would only have allowed 16 or so total.
I've got a new system, but it's going to require some more thought...
was8bit 2022-11-16 05:59 (Edited)
Ah, thanks ... i guessed as such...l just wanted to be sure :)
Actually, if you've noticed, the items in the original game never changed sizes, regardless of how far or how close...
... for items, i am OK with this idea... if the item is more than two squares ahead, or anywhere else, then don't show them... ONLY if they are directly ahead by 1 or 2 squares, show the item without scaling... just have them placed at abit different hights... use the original game as a guide..
... if that helps any, go ahead with that idea, and just scale enemies... generally speaking, there are tons of items, but not as many enemies, so i believe it would be rare to see more than one at a time, with maybe two perhaps... i want my enemies hiding around corners ;)
.. if it helps, you can also represent enemies more than 2 squares away as a shadow, or blob...requiring the player to get closer to see what it really is... you wouldn't need to scale the shadow... it just represents ... something... player cant tell at that distance what it is.. ;)
was8bit 2022-11-16 06:09 (Edited)
Also, if you remember in the original game video, anything past 3 cells ahead is not shown, the space is rendered as black... restricting your graphics might actually complicate your existing code, so i am not saying it is needed, it isnt... what you currently have is fine... :)
... BUT, in the event that less rendering would be somehow easier, and maybe even be helpful, then you can consider that too..
... otherwise just ignore this post ;)
was8bit 2022-11-26 07:38
Oh my goodness... the graphics and animation are WONDERFULL !! :)
nathanielbabiak 2022-11-26 07:45 (Edited)
Hey, was8bit! Check out the new description on this project - it's got a bunch of stuff in there for you to begin messing around with.
Billboard color management is done too, I just don't have a demo yet.
For the billboard animations...
The good news... There's now up to 512 unique billboards allowed in the whole game, and up to six billboards can be displayed on-screen in 3D at once, with any additional visible billboards being rendered as a blob. And, each billboard can be set either "tall" or "wide" (but not both).
The bad news... When the camera encounters a billboard for the first time, it will need at least one second (60 frames) to pre-calculate some render data. After that, animations will render real-time around as fast as today's upload.
Early games addressed this by doing some animation, or playing a sound, etc. The 1996 Gameboy version of Pokemon did this often.
After watching some video of the original Tarmin 1983 game, it seemed like detailed attention (and maybe even a notepad!) would be required to really play it well. For causal modern games, it'd probably be a good idea to animate some text for the user, "hey this is a new item you haven't encountered before! this is what it looks like and what it does..."
Not saying you need to do exactly this, just saying users might feel like the game is frozen if we can't find a way to hide the pre-calculations in some game mechanics.
nathanielbabiak 2022-11-26 07:48 (Edited)
Restart the LRNX file, turn around 180 degrees, and tap [A]!
nathanielbabiak 2022-11-26 07:49 (Edited)
Also, I forgot to mention - I took all the feedback from the Wolf 3D User Poll to create this. It's a bit different, but hopefully everyone likes it.
Timo 2022-11-26 09:29
New version looks great! I like the center-to-sides drawing, it fakes a higher frame rate.
was8bit 2022-11-26 11:55
I am currently heavy with real life work, it will be a few days before i can get the time and brains to look at it in detail...
... it is looking SO COOL ... i cant wait to get into it :)
Dan 2022-11-26 12:40
It is getting better and better.
Amazing !
McPepic 2022-11-26 17:34
Wow. This looks so good! Really impressive work Nathan!
nathanielbabiak 2022-11-27 17:10 (Edited)
Thanks y'all!
Today's upload:
In the 11/26 upload, render quality could be adjusted by holding [B] and tapping arrow keys or tapping [A]. I played around with some choices and came up with the hard-coded values used here.
I think the ray casting engine is done at this point.
On to objects - more to come...
was8bit 2022-11-28 05:31
Maze navigation is fast, smooth, and intuitive... I was able to navigate by my general sense of where I thought I was, and was able to easily work my way thru the maze from one outer side to the opposite outer side... :)
Tomorrow I will be able to spend more time looking at the inner workings :)
nathanielbabiak 2022-11-29 03:55 (Edited)
Use today's upload to go through the code. I renamed and reorganized a bunch of stuff. The MAIN subprogram should actually be pretty easy (finally!)... if you can get a 2D version of your Tarmin working, bringing it into 3D should be pretty easy too.
Also, this upload has SUB B_SCALE_DEMO, a working demo (!) that I'm super proud of.
It's an insanely hard version of Nicky's 3DTree. It uses what I'll call... dark magic, but it'll allow up to 504 billboards, or 168 monotone billboards in each of the three colors (168x3=504). If that isn't enough, we can actually go higher (all the way to 2^15!), but the startup lag will go from a half second to around two FULL seconds, maybe three. (And there's still the initial-encounter lag, unfortunately.)
And (not in the demo), I was able to get some more flexibility out of the billboards, now each one can be either tall or wide. And I increased the number of billboards on-screen simultaneously from six to nine. So the nearest two rows of rooms could be completely full! (Three in the first row, left/right/center, then five in the second row, and you'd have a spare for the third row!)
was8bit 2022-11-29 13:47
Very cool :) unfortunately my life got all busy again, but I will give every effort to dig into the code this week :) you have ressurected my dream, its very exciting :D
was8bit 2022-12-12 20:53
Hiya ... finally got a second to check out the code... i've managed to figure out how to add regular walls randomly... check it out, and hit the PAUSE button to randomize the walls ;)
Of course, for my game, i will create better code that fits within the 4 room setup... the test code was just interested in properly placing all inner wall positions...
nathanielbabiak 2022-12-12 21:22
Great! I'll upload something soon so you can work with items and enemies too. I've got a database for all items and enemies - they'll use what I call an object ID, and also a sequence modifier.
was8bit 2022-12-13 02:44
Cool :)
was8bit 2022-12-13 03:38
Here is my 4 room version... i had to add a dot on char 0 as when editing i inadvertently added other empty characters which effectively added i visible walls ;) so this trick, which is easily removed, makes sure i added char 0 ;)
was8bit 2022-12-13 04:39 (Edited)
Here is my sketched workup for maze data rotation... only the red centered squares store data, with 4 points being either nothing (connected) a wall (not connected), a door(red green), or a secret door (solid green)
... but i am out of time to implement this as a test ... i will have to wait till next week... ive decided to reproduce all the original rooms as the original game, and it should work...
... adding up my actual work time, drive time, and time spent getting ready for work, etc... work consumes 80hrs/week for the awhile, with no signs of changing anytime soon... so maybe next week i will implement my test with this one room data.. :)
was8bit 2022-12-13 04:46
This is one maze, rotating will yield 4 versions of this one maze data... there are 16 original mazes rooms, and each one pops into one of each of the four rooms...
...so 4*16*4 = total number of layouts, or 256 layouts ;)
I will figure out how to add random created rooms later to spice things up... probably when warping out of the main layout...
was8bit 2022-12-13 04:52 (Edited)
... since each room maze is exactly 5x5, and the rooms have open pathways in exactly in the center axis of each room in all directions, if you count in your head as you move, you can predict where to find the pathways in each room...
My random mazes will stick to this format... it stays true to how you navigated in the original game...
.. anyways, "catch u on the flip side"...
nathanielbabiak 2022-12-13 05:10 (Edited)
This update fully incorporates the object database, color management, user input, and item interaction.
The only really screwy thing is that black, dark red, and transparency are kind'a swapped right now, since it's 2D. The 2D will let you focus on big-picture stuff. (The map view code itself rubbish, it won't be in the final version. It's just much easier to explore any changes you make in 2D than in 3D.)
The object database currently includes a bunch of text descriptions too. (Honestly it just makes the database easier to read!) Since the text descriptions are in there already, I figured I'd make a text-adventure style popup message generator too. It's on the pause menu. (It gets weird for cursed doors showing their cursed status even when they're not highlighted. And, adjectives can get disordered. Since it won't appear in the final version, I'm fine with it being a bit buggy.)
The pause menu (and screenshot) also includes the proposed controls for user input. I tested it on a hardware keyboard and the iPad touchscreen buttons, it works surprisingly well.
You'll need to develop the code that makes the objects come alive in the game. I'll continue working on the 3D projection system.
I'll also check out your posts from today too! :-)
nathanielbabiak 2022-12-13 05:20 (Edited)
I went through your posts from today, just wanted to note that the map format in my uploads (the R_BG() array) is a pretty rigid format - changing it will make the 3D renderer too slow.
Totally feel free to develop mazes in any format you wish, and I can develop a converter to get it into the R_BG() format once you've got a few in your format, ready to go.
was8bit 2022-12-13 13:28 (Edited)
I believe I've figured out your format based on the two maps youve included... check out my first random generator code, I carefully edit walls with code in the proper spaces matching yours as they are used in the background maps...
and I am assuming the enemies and items will be added to the empty cell spaces...
... as i will need to generate random maps at some point anyways, I will need to know how to properly edit with code random walls, items, and enemies...
... as for action animation, I believe all I will need is one sprite... animation in the original game is very very basic, showing only one animated thing at a time if i recall correctly...
... I haven't had time to check out your latest update... will post back when I get the chance to check it out, :) but it will be awhile ... your new pause menu looks very useful :)
was8bit 2022-12-19 10:45 (Edited)
I've just now had a chance to dig into the code for your latest update... its looking really cool :) i also like the interface :)
I'm assuming you've disabled the 3d for this current version... the 2d preview is very nice :)
... i tried to change map=3 to map=6 but it seems to start player position outside the map...
Ah... these changes fixed that...
R_CARDINAL=0
R_LOCX=1
R_LOCY=12
was8bit 2022-12-19 11:09
So, a few questions...
If cursed doors are treated and coded in the BG as an enemy, does the object modifier# define which of the four "wall" spaces it resides in...
Also, if item cell#'s #12 and #13 are normal walls, then do #14 and #15 represent walls with secret doors? And also what do #18 and #19 represent??
was8bit 2022-12-19 11:17
... also, if my memory is correct, gates were in the outer hallways, and warped you sideways to another map ... but i am flexible on that as i was't a fan of that format, it seemed more logical to leave the outer hallway empty, and put the warp gate inside a maze room instead...
(A ladder/hole in the floor dropped you down into a lower/harder level...)
I am considering putting warp gates inside, with traditional room mazes to start a level, but warps sends you into a randomized level...
nathanielbabiak 2022-12-19 12:28 (Edited)
In the original game, cursed door "enemies" would only spawn in rooms that were 1x1 with a single entrance. Then that entrance door would be the location of the cursed door. When the player defeated the cursed door, the "enemy" would be replaced with treasure (allowing the door to open normally). The cursed door enemy modifier is just the color.
nathanielbabiak 2022-12-19 12:32
12-13 are normal walls. 14-15 are doors. 18-19 are secret doors. You can try these out - they're in the example level in the upload.
was8bit 2022-12-19 15:45
@cursed doors... ah, thanks for the inside scoop, it's been a long time since I've played a full game of the original... :)
@cell#'s ... thanks much :)
was8bit 2022-12-20 07:04
Here is a rather nice random room maze generator... its simple and yields a predictable layout... its a good start, might tweak it later ...
was8bit 2022-12-20 07:09
It should be easy enough to add secret doors or enemy doors on the deeper levels... ;)
... this was a big push to get this far.. another 80hr week ahead... :/
nathanielbabiak 2022-12-20 12:33
Very nice! Those long work hours can get pretty rough though, take it easy
was8bit 2022-12-20 15:40 (Edited)
Thanks :) I've been doing this for about a few months or so... abit of a blur... not enough help :/ I try to catch up my sleep on my one day off, usually get an extra 8 hours in...
Family is my one fun, and making games is my other fun :)
was8bit 2023-01-09 21:05
Finally got the math for creating and rotating one of the original room mazes..
was8bit 2023-01-09 21:08
Should be very simple to use the data points to add the walls, doors, and secrer doors ;)
... will get it into your program eventually... the code assumes the room walls, which will be standard for all levels, from random or from data...
was8bit 2023-01-09 21:10
... obviously the drawmap is only for checking the data as i enter data for each room... it wont be needed in your game ...
was8bit 2023-07-11 00:16
... so i somehow crashed the code or something...
I created a new random room generator, but it messes up the rendering
I have disabled the code that causes it...
SUB GETROOMS
WAIT 90
REM CALL RNDROOM
Rendering is fine with REM in place... remove REM and rendering botches up...
.... i AM abit tired, maybe i am just missing something???
was8bit 2023-07-11 00:17
I was trying to get the room in one corner.. from there it should be easy to add a random room in any 4 rooms... but i am glitching the rendering somehow :/
was8bit 2023-07-11 00:20
My graphic version works great.... i then changed it into a memory array approach...
nathanielbabiak 2023-07-11 12:47
I'll take a peek after work. It's probably because there needs to be a border around the level. Otherwise, the camera would keep searching (out to an infinite horizon) to find a wall to display.
was8bit 2023-07-11 13:53
Ah... that could be it... i had a lot of trouble getting everything to lined up...
... but then again, i tried testing different portions of my code my adding REM to disable different portions of my code...
This one
REM CALL RNDROOM
Prevents the code that uses an array to figures out where to put walls, but thats all it does, it doesn't edit the actual game
This one
REM IF M=12 OR M=13 THEN R_BG(X+4,Y+4)=M
DOES edit the actual game
With both REM intact, the game then runs smoothly..
But when removing the first REM
REM CALL RNDROOM
to
CALL RNDROOM
BUT still keeping the second REM..
the rendering messes up.. but it shouldn't as the activated code simply runs SUBs that uses its own data and doesnt interfere with main game data..
... so logically it shouldnt be interfering with the rendering...
.... but then again i WAS tired when doing the coding, so who knows...
.... thanks so much for taking the time to look over my code :):):)
McPepic 2023-07-11 15:39
@was8bit
It just looks like the code is failing to clear the last screen completely. Is it possible the new code you wrote to create the random room isn’t setting a buffer involved with the screen drawing? That could cause the tile clearing code to miss it I believe.
was8bit 2023-07-11 15:58
.. so in Tarmin Master 1.002 i use this adjusted code ok..
CALL RXLOADLEVEL( ROM( MAP ) )
CALL RANDMAPGEN
CALL NEWHUD
But in the posted version below i use this code...
CALL RXLOADLEVEL( ROM( MAP ) )
CALL RNDROOM
CALL NEWHUD
Now, RNDROOM simply creates and edirs an arrea MMAP() ... thats all.. so my question is, how does editing my own array cause ANY effect on rendering, or for that matter, have any effect on ANY of the game code as RNDROOM is totally isolated in SUBS and has no effect on the game code???
was8bit 2023-07-11 16:00
By simply adding REM RNDROOM you can run the program just fine, so obviously running RNDROOM causes the issue somehow...
nathanielbabiak 2023-07-12 04:12 (Edited)
Sorry bud. This bug was a doozy. Looks like the renderer assumes BG 0 is active, not BG 1. Within SUB RNDROOM, just insert a BG 0 somewhere. Make sure it's after your nested for loops that use BG 1.
was8bit 2023-07-12 05:44
Yey!!!! Thanks soooo much :)
And if i was awake i would have spotted and removed that BG 1 command... my original code was done graphically, so when i converted it into an array format, i removed all graphical references... except that lone BG 1 command ....
... lesson learned... in the future i will remember this bug ;)
was8bit 2023-07-12 08:18
Check out my latest "beginnings" v1.005 version and test going thru the maze and test if it seems like its fun :)
For this approach i simply created one room layout and copied it to all rooms... since each hallway entry is at a different point into the layout, you do not immediately detect that these rooms are all identical... however they will feel similar and if you get abit lost the similarities cause further confusion ;)
I can tweek the parameters... v1.004 lets you see the core maze without the added secrete doors and gates....
... let me know what you think :)
... i will probably want to try to make a simple one level random game to work out a better understanding of your code ;)
was8bit 2023-07-12 08:20
... also, if you've given me tools or tips, ive forgotten them all :(
was8bit 2023-07-12 08:31 (Edited)
I know you have made mini maps for this.. i was thinking of a pixel map, 10x10 pixels in size..
.. if you've noticed my coordinates 1-12, then 2-11x2-11 (or 1-10x1-10) could be used to show what areas you have or have not entered...
I "think" you may have already made such thing?? I cant remember...
... i could make my own, but it would require 4 characters, but i have no clue what 4 characters that might be free ...
... but, here i go, trying to add complications... i need to stay focused on learning the existing code first...
was8bit 2023-07-12 08:49 (Edited)
So, i am thinking i need to focus on some simple next steps..
...perhaps how to add things to test things... like, food, a simple weapon, and a simple enemy, just to learn how to add and interact with things..
... also to flesh out the user interface to show stats and what a player has, how to pick stuff up, how to use what they have, how to drop off what they have... etc..etc...
... then maybe how add sound effects...
...i'll start right now reading thru the code....
was8bit 2023-07-12 08:54 (Edited)
... one quick question... how does tarmin hud rnd fit in with tarmin master??
... i have been reading up on both... at first glance it seems tarmin hud replaces tarmin master??
... or, perhaps this one up top of this thread replace everything else...?
... sorry, tired brains here... thanks for your patience :)
was8bit 2023-07-13 15:35
So, it seems obvious that this version on this thread is the one i need to start working with.. but i a abit confused...
... QUESTION: how can go to either overview test mode or to actual 3d gameplay mode, i anticipate the need to work back and forth with either mode... i am ok doing it via changing code, i often add/remove different REM statements in my own own code when working on code to test different parts of the code...
Thanks for your help :D
was8bit 2023-07-20 03:23
I love this version, looks fully loaded and ready to go :)
However, i've been reading thru this code, and i still can't figure out how to get to the 3D view :(
nathanielbabiak 2023-07-24 02:32
Going through the uploads now, it seems they're not compatible.
The engine interaction is the same between the latest uploads, but they're no way to switch between overhead view and first-person view, unfortunately.
Also, I'm not sure a database of object descriptions is possible (because of the console token limit).
All that said, you can use the overhead view to check your wall manipulations thoroughly, then copy-paste into the first-person view and do a spot check.
was8bit 2023-07-24 03:36
I actually tried combining the two codes... gave up after several hours...
I have a good visual in my head to where I can “see” in my mind’s eye the overhead view while navigating the 3D maze...
Was able to figure out wall errors hat way with my “Beginnings” version ...
I ran into token limits, but mostly probably because I added both codes together ... what a mess that was ;)
