Forums

Here's a little experiment I'm doing for making a Sega Master System game featuring 3D first-person dungeons. Right now, it's a bit glitchy, and the code is a real mess, but it works.

maze3d-2008-01-09.zip (13.26 KB)

Maze3D 2008-01-09 (alpha)

Apparently not in either Meka or Mess. Meka just sits there with a blank screen and mess boots up the internal rom instead.

I have it running on Meka, but after just a few moves, things just feak out with walls down the middle of the screen and eventually, nothing can happen.

Quote

Apparently not in either Meka or Mess. Meka just sits there with a blank screen and mess boots up the internal rom instead.

That's strange.. I've tested it on Meka and Kega Fusion, and both worked OK.
Well, what version of Meka are you using?
About MESS, hmm... maybe it was because I didn't add a standard SMS header to the ROM, yet.

Quote

I have it running on Meka, but after just a few moves, things just feak out with walls down the middle of the screen and eventually, nothing can happen.

You probably passed through a wall. I haven't implemented collision, yet. =P

Next version shall have both collision checking and a proper SMS header. I'll test it on MESS, too.

Well, here's the new version, with collision checking, corrected ROM header, a simple animation when turning around, and tested on various emulators to make sure it's running.
Tested on Meka 0.71, Emukon 1.05, MesaDX 0.04, MESS 0.100, Kega Fusion 3.5

maze3d-2008-01-10.zip (13.94 KB)

Maze3D 2008-01-10 (alpha)

Meka 0.72 - same result

haroldoop: latest build works in both Meka 0.72 and Fusion here (first didn't). Looks cool so far! Would probably look even better with some nicer pixelled wall-tiles, but I'm not familiar with SMS gfx limitations/palettes yet so it's hard for me to judge that accurately.

but it's looking good

Quote

Meka 0.72 - same result

That's reallly strange... I've just downloaded Meka version 0.72 for windows, and the game ran on it with no problems. O.o

Quote

latest build works in both Meka 0.72 and Fusion here (first didn't)

I'm glad to know that it works now. ;)

Quote

Would probably look even better with some nicer pixelled wall-tiles, but I'm not familiar with SMS gfx limitations/palettes yet so it's hard for me to judge that accurately.

Yes, I can actually make it more detailed, this is just a test. When planning how to implement the 3D dungeons, I've thought of those four possibilities:

- Dynamic tileset changing: Would alow me to do very detailed visuals, but at the cost of speed, ROM space, and a pretty small view window.

- Four color, "fake" 64x48: I could set up the first 256 tiles in a way that would allow me to create a fake 64x48 pixels (big pixels) fullscreen image, with all the pixels addressable. It would be fast, it would consume very little ROM space, but the disadvantages are pretty obvious.

- Use each background tile as a big pixel, using dithering for colors: Although the resulting resolution would be still smaller than the above, it would be blazing fast. I do intend to experiment with making a raycasting engine using this option. Maybe it won't look as bad when in movement.

- Manually design a fixed tileset and carefully combine those tiles to build the 3D-views: While this does mean a certain amount of manual tile/background editing, it would allow one to make reasonably detailed visuals without much ROM expense, and the screen updating would be pretty fast. That was the option which I ultimately chose.

If you want to take a look at the kind of visual quality I'm trying to reach, take a look at the NES version of Might and Magic, and imagine it with 16 colors instead of four. Note that the game I'm designing may not be necessarily a RPG; I'm leaning more toward making a Xybots-like 3rd person shooter, with some RPG elements thrown in. Or, maybe, a first-person roguelike.

haroldoop wrote

Quote

Meka 0.72 - same result

That's reallly strange... I've just downloaded Meka version 0.72 for windows, and the game ran on it with no problems. O.o

Nevermind it works fine, the problem was my own. I normally extract roms before using them but since discovering Meka can read zipped roms i've been opening them that way instead.

Looks great now I've got it running, it very reminisc of the early 3D RPGs back in the day.

The only thing I picked up on is the method of turning, I can understand you probably did it that way due to technical limitations but its disorientating when an isometric wall morphs into a flat one, if you cant do it any other way it'd probably be better to forget the transition effect and just switch to the new facing directly.

I've just noticed you've included some source in C. Are you using home rolled sms libraries or does there exist a functional API somewhere I could get a hold of?

I'm still trying to learn assembly so I can write my own roms which is progressing slower than i'd like, but if I could use C instead I'd be pumping out roms in a jiffy.

Quote

Nevermind it works fine, the problem was my own. I normally extract roms before using them but since discovering Meka can read zipped roms i've been opening them that way instead.

XD

Quote

The only thing I picked up on is the method of turning, I can understand you probably did it that way due to technical limitations but its disorientating when an isometric wall morphs into a flat one, if you cant do it any other way it'd probably be better to forget the transition effect and just switch to the new facing directly.

I agree. I just made it that way as a experiment, to see how it would look. Besides, removing the transition effect would save some RAM, too. =P

Quote

I've just noticed you've included some source in C. Are you using home rolled sms libraries or does there exist a functional API somewhere I could get a hold of?

I'm still trying to learn assembly so I can write my own roms which is progressing slower than i'd like, but if I could use C instead I'd be pumping out roms in a jiffy.

I'm using z88dk, along with some C libraries I made available to the forums some time ago. (http://www.smspower.org/forums/viewtopic.php?t=8176 and http://www.smspower.org/forums/viewtopic.php?t=9158).
Obs: The newest version of z88dk (1.7) has incorporated these libraries, too.

Good luck, and have fun! 8)

Here's a new version, I'm testing a possible Xybots-like 3rd person view.
Use arrows to walk around, and button 2 + left or right to turn around.
Please note that the current graphics are just a temporary placeholder.

maze3d-2008-01-14.zip (38.84 KB)

Maze3D 2008-01-14 (alpha; 3rd person test)

Now that looks pretty good, very Xybot'ish indeed. I did notice a lot of the RAM data that is used is at the bottom, and since my C is rusty and don't know how to use it for SMS purposes, are you using the stack. I only comment since most of the values in rom are dangerously close to the end or Ram and if you use the stack later, it can get dangerously close to accidentally overwriting some of the RAM data.

Never played Xybots but its very weird now, completely different style of game.

What's with the odd jumping around when you turn? (a diamond pattern from looks).

That I think I can answer... if you were standing and facing say.. north at the right most part of the square, when you rotate to the east, you are now at the front of the square. Turn to the south, you are at the left, all based on perspective.

The effect is a bot more obvious in Xybots, since the maze rotates a few frames when you do said rotate, and the player tweens into that position in time with the rotation.

Quote

I did notice a lot of the RAM data that is used is at the bottom, and since my C is rusty and don't know how to use it for SMS purposes, are you using the stack. I only comment since most of the values in rom are dangerously close to the end or Ram and if you use the stack later, it can get dangerously close to accidentally overwriting some of the RAM data.

Actually, I'm using the stack. The problem with the version of z88dk that I currently use is that it puts all the global variables, initialized or not, on the same region as code, meaning that either you keep everything in ROM (making global variables unchangeable) or you keep everything in RAM (then code would also be kept in RAM, meaning your game couldn't be bigger than 8k). A way to use global variables while keeping the code in ROM would be to use the DEFVARS assembly directive to statically allocate RAM, but I opted to use the stack, instead. I know this is pretty inneficient, though.
Someday, I'll have to take a look at version 1.7 to see if it solved this limitation on the memory organization. =P

Quote

Never played Xybots but its very weird now, completely different style of game.
What's with the odd jumping around when you turn? (a diamond pattern from looks).

Quote

That I think I can answer... if you were standing and facing say.. north at the right most part of the square, when you rotate to the east, you are now at the front of the square. Turn to the south, you are at the left, all based on perspective.

Well, AtariRaccoon explained it all. :)

I was gonna say. Now that I think of it, from the dounds of it, you would probably have to use pointers in C to be able to access a point in ram. But since my knowledge of z88dk is nil, I'm only making blind assumptions.

Quote

I was gonna say. Now that I think of it, from the dounds of it, you would probably have to use pointers in C to be able to access a point in ram. But since my knowledge of z88dk is nil, I'm only making blind assumptions.

Well, yes, z88dk allows you to access the RAM through pointers with no problems. The difficulty lies on allocating global variables, since, as said before, it allocates the data on the same memory region as code, unless you manually specify the address of each variable (the assembler directive DEFVARS can simplify this task a little). This can be a trouble, since you generally want the variables to be allocated in RAM, and code in ROM.

haroldoop wrote

.... unless you manually specify the address of each variable...

That's basically what you have to do even in assembler. We just use a code-level constant (ie .define Xposition $C000) and use specific z80 commands that act like pointers
ie ld a,(Xposition) would stick the value in ram address $C000 to the A register

Actually, that's what all higher-level languages and compilers do, but behind the scenes, so you just have to use a name, the compiler just turns it to a pointer in RAM. Hence what seems the problem with z88dk, the compiler hasn't been taught that vairables have to be store in address $C000 and up.

The devs have already said that they want to add this feature and support ROM'able code a little better, but it basically requires a full rewrite of z88dk.

So I geuss its a matter of waiting for them to be hit with some devine inspiration.

Here's a new version, with floor/ceiling support added.

BTW, I would like to hear some opinions about what kind of game I should make by using this engine. Keep in mind that the current 3rd person view is just a test to see how well it could be done, it may or may not be used on the final game. Should the engine be used for an action game? What features should it have? Should it be made into a RPG? What kind of battle system would best fit it?

maze3d-2008-01-16.zip (38.78 KB)

Maze3D 2008-01-16 (alpha)

The static nature of the 3D world and lack of processing power ftom the z80 limits the possibilities with any game in the action category. If you did it would have to be something unique.

Its well suited to RPG of course but that area may have been done to death already.

I think for something a bit different you could try making an adventure game out of it.

I still find his style of turning a bit weird. It doesn't seem right for example to be standing perfectly in the middle of the screen one second then off to the far left side the next.

The other thing I notice is that the figure wraps around the screen when moving forward/back before the next screen has loaded. It would be better I think to update the world view before wrapping the character back around.

It looks great, but I agree that turning (or lack thereof) feels a little awkward.
I'd have thought that being able to turn in 90 degree increments should be realtively easy to implement.

Rather than Phantasy Star-style smooth rotation, a simple trick is to have a "before" and "after" turning frame and to simply pan horizontally from one to the other in the direction of the turn. (Example screenshot).

That's exactly what it did in the earlier version I tried. It looked awful - maybe if it was faster it would look better?

benryves wrote

Rather than Phantasy Star-style smooth rotation, a simple trick is to have a "before" and "after" turning frame and to simply pan horizontally from one to the other in the direction of the turn. (Example screenshot).

Actually thats exactly what one of his original versions did, but the aspect ratios he chose for the walls did not lend themselves well to the effect. The end result was a 2 tile wall section sliding into a 4 tile wall section which looked clunky and felt disorientating.

Never played Phantasy Star but just watched a video of the maze section, I'm quite impressed with what they achieved. Anyone know the technique they used, did they make an entire tileset just for the turning animation or was some other trickery involved?

There are multiple tilesets for turning, I think they're streamed from ROM somehow (maybe stored as 2bpp?). They simplified matters somewhat by not being able to render the geometry perfectly while turning (so the screen animates from wall/corridor to wall/corridor without rendering side turns or doors), and of course all PS dungeons are only one map tile wide, and you can't see very far ahead, so there's a reduced number of possible views when not turning too.

I seem to remember part of a Phantasy Star interview somewhere saying they could have rendered the dungeons at a higher frame rate, the limit was only ROM space.

Sorry, I missed that (and that you can still turn with button 2). I don't think the scrolling effect looks that bad (I much prefer it to the sudden jump, but I think I'm in the minority there).

Quote

The static nature of the 3D world and lack of processing power ftom the z80 limits the possibilities with any game in the action category. If you did it would have to be something unique.

Just tried adding an enemy today, and now the game runs at half speed. =P
No problem. I know what's slowing it down, and will try to fix the speed problem later.

Quote

Its well suited to RPG of course but that area may have been done to death already.

Very true, it would be fairly easy to simply add some static (or, maybe, animated but unmoving) enemies to the screen, to comprise a RPG-like battle system, but, as quoted above, that has already been done to death, though, of course, if there's enough interest, it could be worth a try.

Quote

I still find his style of turning a bit weird. It doesn't seem right for example to be standing perfectly in the middle of the screen one second then off to the far left side the next.

Yes, the fact the sudden movent can be a bit disorienting.

Quote

The other thing I notice is that the figure wraps around the screen when moving forward/back before the next screen has loaded. It would be better I think to update the world view before wrapping the character back around.

Mmm... that would be pretty easy to do. I'll have a try.

Quote

Rather than Phantasy Star-style smooth rotation, a simple trick is to have a "before" and "after" turning frame and to simply pan horizontally from one to the other in the direction of the turn. (Example screenshot).

Quote

That's exactly what it did in the earlier version I tried. It looked awful - maybe if it was faster it would look better?

Quote

Actually thats exactly what one of his original versions did, but the aspect ratios he chose for the walls did not lend themselves well to the effect. The end result was a 2 tile wall section sliding into a 4 tile wall section which looked clunky and felt disorientating.

Well, I had tried to use a scrolling effect for a "fake" rotation effect, but couldn't make it look good; unfortunately, not even varying the speed helped. =P

Worked nice for me on Dega...
Good job, maybe you now could put some more action onto it and background music...

If the rotation has to be a transition, why not make it so, by using some kind of low-tech Powerpoint transition? A slide looked bad, how about a wipe or "blinds" transition?

I'm a firm believer in the keep-it-simple-stupid approach.

Unless you are going to make a propper turn or transition effect don't bother at all. Adding cheap effects to a cheap turning method is not the recipe for success.

My suggestion would be keep the turning as is, nice simple 90 degree turns at a time. Get rid of the perspective effect, it doesn't work, and unless you radically change your engine its not going to work.

Also don't try and make a game based around an engine, make the engine based around the game. Decide first exactly what genre your gunning for and a rough outline for a possible gameplay mechanic.

Quote

Good job, maybe you now could put some more action onto it and background music...

The suggestion about the background music made me remember something: I can't make the VDP interrupt work with the C compiler. It gets called, the routine runs, but the execution never returns to the main program, the interrupt just gets called over and over again. Strangely enough, the pause interrupt works with no problems, and it's coded almost the same way. For those who may want to take a look at it, the interrupt handling code is on line 66 of sms_crt0 asm, on the compiler's lib directory. Just enable VBL interrupts, and there it goes crashing... =P

Quote

If the rotation has to be a transition, why not make it so, by using some kind of low-tech Powerpoint transition? A slide looked bad, how about a wipe or "blinds" transition?

Mm... no, I don't think it would look very good in this case, though it would surely look nice on a intro screen.

Quote

Unless you are going to make a propper turn or transition effect don't bother at all. Adding cheap effects to a cheap turning method is not the recipe for success.

My suggestion would be keep the turning as is, nice simple 90 degree turns at a time. Get rid of the perspective effect, it doesn't work, and unless you radically change your engine its not going to work.

Well, thanks for the suggestions.

Quote

Also don't try and make a game based around an engine, make the engine based around the game. Decide first exactly what genre your gunning for and a rough outline for a possible gameplay mechanic.

I'm actually trying to do both at the same time. Sometimes, the engine can inspire a game, and vice-versa. But my original idea was either doing a sci-fi third person shooter with some RPG elements, or a first person roguelike, but I'm always open to suggestions.

Anyway, here's a new version. I tried to add an enemy, but the engine slows down noticeably when it's present on screen, even after speeding up the perspective calculations. The enemy's sprite also looks corrupted because it's being rendered at the wrong size, but I didn't bother to fix it, yet.

Next version, I'll try an RPG battle engine, instead.

maze3d-2008-01-18.zip (41.15 KB)

Maze3D 2008-01-18 (alpha)

Well, here's a new version, going back to the first person engine, and beginning implementation of a RPG-styled battle system.
The green "things" you see on the screen are supposed to be enemies. Once implemented, it'll be the old traditional game mechanics: The player will walk around for a while, and then, suddenly the enemies will appear in front of him, and then the game will enter battle mode.
As can be seen, there are only two enemies on screen. That's because of the 8 sprite per line limit, even though, so far, little less than one third of the maximum sprites per screen are in use. Later, I intend to experiment with combining sprites and backgroud tiles to get around this limit. Adding some flying enemies would also help getting around this. =P

maze3d-2008-01-21.zip (40.88 KB)

Maze3D 2008-01-21 (alpha)

Hay, this looks really cool. I hope you continue on with it.

Quote

Hay, this looks really cool. I hope you continue on with it.

Don't worry, it will be put on ice for a while, until I do something for the PDROMs coding competition, then I'll get back to it.

I love it!!! It reminds me of Dungeon Master. Oh where are those dungeon times...

Sort of offtopic. Sprite-based 3d engine can be used to make somewhat playable Wolfenstein 3d-like action game. That was proved by 'Doom' demo made in 1996-97 for russian ZX Spectrum clones (check video on YouTube). It uses sprites to display walls, objects, and even floor texture; allows to rotate and move in 32 directions; has some different wall textures and 6 types of enemies per level (up to four on screen). Works on 3.5 MHz Z80, 128K RAM. Game wasn't finished, but playable demo with one level, some enemies and weapons was released. Advance of Spectrum that it has 6K video memory in Z80 address space, so it can do software render faster than SMS, but maybe similar tech can be used on SMS too.

Yes, I saw that one, and also Wolfenstein 2004, by the same guys, if I'm not mistaken (there's source for that one available, but I haven't been able to read it), and also a similar game for the TI-85 (For which there's z80 asm source available too, and that one is readable (well, it's not commented, but you can read it)).
I also studied the possibility of implementing a raycasting engine heavily based on pre-calculated tables, but I didn't get to the coding stage.
For those who are interested on the 3D-dungeon project: I haven't quit yet, I just have been on a severe lack of free time lately... =P

haroldoop wrote

Yes, I saw that one, and also Wolfenstein 2004, by the same guys, if I'm not mistaken

I'm one of guys behind the Wolfenstein 2004 (I made level editor, some gfx, etc). We are not related to authors of 'Doom' at all. Last demo of Doom was released in 1997, Wolf project was started in 1996 and, with pauses for years, finished in 2004. Wolf'2004 uses raycasting, but slightly different from classic one, which was used in original Wolf for PC (it has 'paper' walls instead of 'cubes', for example). Sources of Wolf'2004 can be converted in plain text, but they heavily relies for features of Alasm (advanced native ZX assembler). Main author of Wolf'2004, Alone Coder, speak english and can answer to questions if needed (PM me for contacts).

Whoops... =P
Sorry for the mistake, and thanks for the info. :)

Author	Message
haroldoop Joined: 25 Feb 2006 Posts: 157 Location: Belo Horizonte, MG, Brazil	3D Dungeon Posted: Thu Jan 10, 2008 1:19 am
	Here's a little experiment I'm doing for making a Sega Master System game featuring 3D first-person dungeons. Right now, it's a bit glitchy, and the code is a real mess, but it works. maze3d-2008-01-09.zip (13.26 KB) Maze3D 2008-01-09 (alpha)

djbass Joined: 25 Jul 2007 Posts: 512 Location: Melbourne, Australia	Posted: Thu Jan 10, 2008 4:16 am
	Apparently not in either Meka or Mess. Meka just sits there with a blank screen and mess boots up the internal rom instead.

AtariRaccoon Joined: 24 Sep 2007 Posts: 99 Location: Canada - NB	Posted: Thu Jan 10, 2008 5:22 am
	I have it running on Meka, but after just a few moves, things just feak out with walls down the middle of the screen and eventually, nothing can happen.

haroldoop Joined: 25 Feb 2006 Posts: 157 Location: Belo Horizonte, MG, Brazil	Posted: Thu Jan 10, 2008 9:26 pm
	Quote Apparently not in either Meka or Mess. Meka just sits there with a blank screen and mess boots up the internal rom instead. That's strange.. I've tested it on Meka and Kega Fusion, and both worked OK. Well, what version of Meka are you using? About MESS, hmm... maybe it was because I didn't add a standard SMS header to the ROM, yet. Quote I have it running on Meka, but after just a few moves, things just feak out with walls down the middle of the screen and eventually, nothing can happen. You probably passed through a wall. I haven't implemented collision, yet. =P Next version shall have both collision checking and a proper SMS header. I'll test it on MESS, too.

haroldoop Joined: 25 Feb 2006 Posts: 157 Location: Belo Horizonte, MG, Brazil	3D Dungeon Posted: Thu Jan 10, 2008 10:37 pm
	Well, here's the new version, with collision checking, corrected ROM header, a simple animation when turning around, and tested on various emulators to make sure it's running. Tested on Meka 0.71, Emukon 1.05, MesaDX 0.04, MESS 0.100, Kega Fusion 3.5 maze3d-2008-01-10.zip (13.94 KB) Maze3D 2008-01-10 (alpha)

djbass Joined: 25 Jul 2007 Posts: 512 Location: Melbourne, Australia	Posted: Thu Jan 10, 2008 10:45 pm
	Meka 0.72 - same result

arkanoid Joined: 08 Jan 2008 Posts: 5	Posted: Thu Jan 10, 2008 11:05 pm
arkanoid Joined: 08 Jan 2008 Posts: 5	haroldoop: latest build works in both Meka 0.72 and Fusion here (first didn't). Looks cool so far! Would probably look even better with some nicer pixelled wall-tiles, but I'm not familiar with SMS gfx limitations/palettes yet so it's hard for me to judge that accurately. but it's looking good

haroldoop Joined: 25 Feb 2006 Posts: 157 Location: Belo Horizonte, MG, Brazil	Posted: Thu Jan 10, 2008 11:08 pm
	Quote Meka 0.72 - same result That's reallly strange... I've just downloaded Meka version 0.72 for windows, and the game ran on it with no problems. O.o

haroldoop Joined: 25 Feb 2006 Posts: 157 Location: Belo Horizonte, MG, Brazil	Posted: Thu Jan 10, 2008 11:43 pm
	Quote latest build works in both Meka 0.72 and Fusion here (first didn't) I'm glad to know that it works now. ;) Quote Would probably look even better with some nicer pixelled wall-tiles, but I'm not familiar with SMS gfx limitations/palettes yet so it's hard for me to judge that accurately. Yes, I can actually make it more detailed, this is just a test. When planning how to implement the 3D dungeons, I've thought of those four possibilities: - Dynamic tileset changing: Would alow me to do very detailed visuals, but at the cost of speed, ROM space, and a pretty small view window. - Four color, "fake" 64x48: I could set up the first 256 tiles in a way that would allow me to create a fake 64x48 pixels (big pixels) fullscreen image, with all the pixels addressable. It would be fast, it would consume very little ROM space, but the disadvantages are pretty obvious. - Use each background tile as a big pixel, using dithering for colors: Although the resulting resolution would be still smaller than the above, it would be blazing fast. I do intend to experiment with making a raycasting engine using this option. Maybe it won't look as bad when in movement. - Manually design a fixed tileset and carefully combine those tiles to build the 3D-views: While this does mean a certain amount of manual tile/background editing, it would allow one to make reasonably detailed visuals without much ROM expense, and the screen updating would be pretty fast. That was the option which I ultimately chose. If you want to take a look at the kind of visual quality I'm trying to reach, take a look at the NES version of Might and Magic, and imagine it with 16 colors instead of four. Note that the game I'm designing may not be necessarily a RPG; I'm leaning more toward making a Xybots-like 3rd person shooter, with some RPG elements thrown in. Or, maybe, a first-person roguelike.

djbass Joined: 25 Jul 2007 Posts: 512 Location: Melbourne, Australia	Posted: Fri Jan 11, 2008 4:15 am
	haroldoop wrote Quote Meka 0.72 - same result That's reallly strange... I've just downloaded Meka version 0.72 for windows, and the game ran on it with no problems. O.o Nevermind it works fine, the problem was my own. I normally extract roms before using them but since discovering Meka can read zipped roms i've been opening them that way instead. Looks great now I've got it running, it very reminisc of the early 3D RPGs back in the day. The only thing I picked up on is the method of turning, I can understand you probably did it that way due to technical limitations but its disorientating when an isometric wall morphs into a flat one, if you cant do it any other way it'd probably be better to forget the transition effect and just switch to the new facing directly.

djbass Joined: 25 Jul 2007 Posts: 512 Location: Melbourne, Australia	Posted: Fri Jan 11, 2008 4:26 am
	I've just noticed you've included some source in C. Are you using home rolled sms libraries or does there exist a functional API somewhere I could get a hold of? I'm still trying to learn assembly so I can write my own roms which is progressing slower than i'd like, but if I could use C instead I'd be pumping out roms in a jiffy.

haroldoop Joined: 25 Feb 2006 Posts: 157 Location: Belo Horizonte, MG, Brazil	Posted: Fri Jan 11, 2008 9:55 pm
	Quote Nevermind it works fine, the problem was my own. I normally extract roms before using them but since discovering Meka can read zipped roms i've been opening them that way instead. XD Quote The only thing I picked up on is the method of turning, I can understand you probably did it that way due to technical limitations but its disorientating when an isometric wall morphs into a flat one, if you cant do it any other way it'd probably be better to forget the transition effect and just switch to the new facing directly. I agree. I just made it that way as a experiment, to see how it would look. Besides, removing the transition effect would save some RAM, too. =P Quote I've just noticed you've included some source in C. Are you using home rolled sms libraries or does there exist a functional API somewhere I could get a hold of? I'm still trying to learn assembly so I can write my own roms which is progressing slower than i'd like, but if I could use C instead I'd be pumping out roms in a jiffy. I'm using z88dk, along with some C libraries I made available to the forums some time ago. (http://www.smspower.org/forums/viewtopic.php?t=8176 and http://www.smspower.org/forums/viewtopic.php?t=9158). Obs: The newest version of z88dk (1.7) has incorporated these libraries, too. Good luck, and have fun! 8)

haroldoop Joined: 25 Feb 2006 Posts: 157 Location: Belo Horizonte, MG, Brazil	New version: 3rd person test Posted: Tue Jan 15, 2008 12:46 am
	Here's a new version, I'm testing a possible Xybots-like 3rd person view. Use arrows to walk around, and button 2 + left or right to turn around. Please note that the current graphics are just a temporary placeholder. maze3d-2008-01-14.zip (38.84 KB) Maze3D 2008-01-14 (alpha; 3rd person test)

AtariRaccoon Joined: 24 Sep 2007 Posts: 99 Location: Canada - NB	Posted: Tue Jan 15, 2008 3:08 am
	Now that looks pretty good, very Xybot'ish indeed. I did notice a lot of the RAM data that is used is at the bottom, and since my C is rusty and don't know how to use it for SMS purposes, are you using the stack. I only comment since most of the values in rom are dangerously close to the end or Ram and if you use the stack later, it can get dangerously close to accidentally overwriting some of the RAM data.

djbass Joined: 25 Jul 2007 Posts: 512 Location: Melbourne, Australia	Posted: Tue Jan 15, 2008 4:29 am
	Never played Xybots but its very weird now, completely different style of game. What's with the odd jumping around when you turn? (a diamond pattern from looks).

AtariRaccoon Joined: 24 Sep 2007 Posts: 99 Location: Canada - NB	Posted: Tue Jan 15, 2008 5:19 am
	That I think I can answer... if you were standing and facing say.. north at the right most part of the square, when you rotate to the east, you are now at the front of the square. Turn to the south, you are at the left, all based on perspective. The effect is a bot more obvious in Xybots, since the maze rotates a few frames when you do said rotate, and the player tweens into that position in time with the rotation.

haroldoop Joined: 25 Feb 2006 Posts: 157 Location: Belo Horizonte, MG, Brazil	Posted: Tue Jan 15, 2008 10:20 pm
	Quote I did notice a lot of the RAM data that is used is at the bottom, and since my C is rusty and don't know how to use it for SMS purposes, are you using the stack. I only comment since most of the values in rom are dangerously close to the end or Ram and if you use the stack later, it can get dangerously close to accidentally overwriting some of the RAM data. Actually, I'm using the stack. The problem with the version of z88dk that I currently use is that it puts all the global variables, initialized or not, on the same region as code, meaning that either you keep everything in ROM (making global variables unchangeable) or you keep everything in RAM (then code would also be kept in RAM, meaning your game couldn't be bigger than 8k). A way to use global variables while keeping the code in ROM would be to use the DEFVARS assembly directive to statically allocate RAM, but I opted to use the stack, instead. I know this is pretty inneficient, though. Someday, I'll have to take a look at version 1.7 to see if it solved this limitation on the memory organization. =P Quote Never played Xybots but its very weird now, completely different style of game. What's with the odd jumping around when you turn? (a diamond pattern from looks). Quote That I think I can answer... if you were standing and facing say.. north at the right most part of the square, when you rotate to the east, you are now at the front of the square. Turn to the south, you are at the left, all based on perspective. Well, AtariRaccoon explained it all. :)

AtariRaccoon Joined: 24 Sep 2007 Posts: 99 Location: Canada - NB	Posted: Tue Jan 15, 2008 10:39 pm
	I was gonna say. Now that I think of it, from the dounds of it, you would probably have to use pointers in C to be able to access a point in ram. But since my knowledge of z88dk is nil, I'm only making blind assumptions.

haroldoop Joined: 25 Feb 2006 Posts: 157 Location: Belo Horizonte, MG, Brazil	Posted: Tue Jan 15, 2008 11:27 pm
	Quote I was gonna say. Now that I think of it, from the dounds of it, you would probably have to use pointers in C to be able to access a point in ram. But since my knowledge of z88dk is nil, I'm only making blind assumptions. Well, yes, z88dk allows you to access the RAM through pointers with no problems. The difficulty lies on allocating global variables, since, as said before, it allocates the data on the same memory region as code, unless you manually specify the address of each variable (the assembler directive DEFVARS can simplify this task a little). This can be a trouble, since you generally want the variables to be allocated in RAM, and code in ROM.

AtariRaccoon Joined: 24 Sep 2007 Posts: 99 Location: Canada - NB	Posted: Wed Jan 16, 2008 2:27 am Last edited by AtariRaccoon on Wed Jan 16, 2008 4:50 pm; edited 1 time in total
	haroldoop wrote .... unless you manually specify the address of each variable... That's basically what you have to do even in assembler. We just use a code-level constant (ie .define Xposition $C000) and use specific z80 commands that act like pointers ie ld a,(Xposition) would stick the value in ram address $C000 to the A register Actually, that's what all higher-level languages and compilers do, but behind the scenes, so you just have to use a name, the compiler just turns it to a pointer in RAM. Hence what seems the problem with z88dk, the compiler hasn't been taught that vairables have to be store in address $C000 and up.

djbass Joined: 25 Jul 2007 Posts: 512 Location: Melbourne, Australia	Posted: Wed Jan 16, 2008 4:02 am
	The devs have already said that they want to add this feature and support ROM'able code a little better, but it basically requires a full rewrite of z88dk. So I geuss its a matter of waiting for them to be hit with some devine inspiration.

haroldoop Joined: 25 Feb 2006 Posts: 157 Location: Belo Horizonte, MG, Brazil	Posted: Thu Jan 17, 2008 12:10 am
	Here's a new version, with floor/ceiling support added. BTW, I would like to hear some opinions about what kind of game I should make by using this engine. Keep in mind that the current 3rd person view is just a test to see how well it could be done, it may or may not be used on the final game. Should the engine be used for an action game? What features should it have? Should it be made into a RPG? What kind of battle system would best fit it? maze3d-2008-01-16.zip (38.78 KB) Maze3D 2008-01-16 (alpha)

djbass Joined: 25 Jul 2007 Posts: 512 Location: Melbourne, Australia	Posted: Thu Jan 17, 2008 4:54 am
	The static nature of the 3D world and lack of processing power ftom the z80 limits the possibilities with any game in the action category. If you did it would have to be something unique. Its well suited to RPG of course but that area may have been done to death already. I think for something a bit different you could try making an adventure game out of it.

djbass Joined: 25 Jul 2007 Posts: 512 Location: Melbourne, Australia	Posted: Thu Jan 17, 2008 5:09 am
	I still find his style of turning a bit weird. It doesn't seem right for example to be standing perfectly in the middle of the screen one second then off to the far left side the next. The other thing I notice is that the figure wraps around the screen when moving forward/back before the next screen has loaded. It would be better I think to update the world view before wrapping the character back around.

benryves Joined: 12 Apr 2005 Posts: 366 Location: Purley, England	Posted: Thu Jan 17, 2008 10:59 am
	It looks great, but I agree that turning (or lack thereof) feels a little awkward. I'd have thought that being able to turn in 90 degree increments should be realtively easy to implement. Rather than Phantasy Star-style smooth rotation, a simple trick is to have a "before" and "after" turning frame and to simply pan horizontally from one to the other in the direction of the turn. (Example screenshot).

Maxim Site Admin Joined: 19 Oct 1999 Posts: 8982 Location: London	Posted: Thu Jan 17, 2008 11:40 am
	That's exactly what it did in the earlier version I tried. It looked awful - maybe if it was faster it would look better?

djbass Joined: 25 Jul 2007 Posts: 512 Location: Melbourne, Australia	Posted: Thu Jan 17, 2008 1:57 pm
	benryves wrote Rather than Phantasy Star-style smooth rotation, a simple trick is to have a "before" and "after" turning frame and to simply pan horizontally from one to the other in the direction of the turn. (Example screenshot). Actually thats exactly what one of his original versions did, but the aspect ratios he chose for the walls did not lend themselves well to the effect. The end result was a 2 tile wall section sliding into a 4 tile wall section which looked clunky and felt disorientating. Never played Phantasy Star but just watched a video of the maze section, I'm quite impressed with what they achieved. Anyone know the technique they used, did they make an entire tileset just for the turning animation or was some other trickery involved?

Maxim Site Admin Joined: 19 Oct 1999 Posts: 8982 Location: London	Posted: Thu Jan 17, 2008 3:02 pm
	There are multiple tilesets for turning, I think they're streamed from ROM somehow (maybe stored as 2bpp?). They simplified matters somewhat by not being able to render the geometry perfectly while turning (so the screen animates from wall/corridor to wall/corridor without rendering side turns or doors), and of course all PS dungeons are only one map tile wide, and you can't see very far ahead, so there's a reduced number of possible views when not turning too. I seem to remember part of a Phantasy Star interview somewhere saying they could have rendered the dungeons at a higher frame rate, the limit was only ROM space.

benryves Joined: 12 Apr 2005 Posts: 366 Location: Purley, England	Posted: Thu Jan 17, 2008 5:35 pm
	Sorry, I missed that (and that you can still turn with button 2). I don't think the scrolling effect looks that bad (I much prefer it to the sudden jump, but I think I'm in the minority there).

haroldoop Joined: 25 Feb 2006 Posts: 157 Location: Belo Horizonte, MG, Brazil	Posted: Thu Jan 17, 2008 10:09 pm
	Quote The static nature of the 3D world and lack of processing power ftom the z80 limits the possibilities with any game in the action category. If you did it would have to be something unique. Just tried adding an enemy today, and now the game runs at half speed. =P No problem. I know what's slowing it down, and will try to fix the speed problem later. Quote Its well suited to RPG of course but that area may have been done to death already. Very true, it would be fairly easy to simply add some static (or, maybe, animated but unmoving) enemies to the screen, to comprise a RPG-like battle system, but, as quoted above, that has already been done to death, though, of course, if there's enough interest, it could be worth a try. Quote I still find his style of turning a bit weird. It doesn't seem right for example to be standing perfectly in the middle of the screen one second then off to the far left side the next. Yes, the fact the sudden movent can be a bit disorienting. Quote The other thing I notice is that the figure wraps around the screen when moving forward/back before the next screen has loaded. It would be better I think to update the world view before wrapping the character back around. Mmm... that would be pretty easy to do. I'll have a try. Quote Rather than Phantasy Star-style smooth rotation, a simple trick is to have a "before" and "after" turning frame and to simply pan horizontally from one to the other in the direction of the turn. (Example screenshot). Quote That's exactly what it did in the earlier version I tried. It looked awful - maybe if it was faster it would look better? Quote Actually thats exactly what one of his original versions did, but the aspect ratios he chose for the walls did not lend themselves well to the effect. The end result was a 2 tile wall section sliding into a 4 tile wall section which looked clunky and felt disorientating. Well, I had tried to use a scrolling effect for a "fake" rotation effect, but couldn't make it look good; unfortunately, not even varying the speed helped. =P

Rony_ket Joined: 09 May 2007 Posts: 135 Location: Sampa, Brazil	Posted: Thu Jan 17, 2008 10:40 pm
	Worked nice for me on Dega... Good job, maybe you now could put some more action onto it and background music...

Maxim Site Admin Joined: 19 Oct 1999 Posts: 8982 Location: London	Posted: Fri Jan 18, 2008 9:10 am
	If the rotation has to be a transition, why not make it so, by using some kind of low-tech Powerpoint transition? A slide looked bad, how about a wipe or "blinds" transition?

djbass Joined: 25 Jul 2007 Posts: 512 Location: Melbourne, Australia	Posted: Fri Jan 18, 2008 9:58 am
	I'm a firm believer in the keep-it-simple-stupid approach. Unless you are going to make a propper turn or transition effect don't bother at all. Adding cheap effects to a cheap turning method is not the recipe for success. My suggestion would be keep the turning as is, nice simple 90 degree turns at a time. Get rid of the perspective effect, it doesn't work, and unless you radically change your engine its not going to work. Also don't try and make a game based around an engine, make the engine based around the game. Decide first exactly what genre your gunning for and a rough outline for a possible gameplay mechanic.

haroldoop Joined: 25 Feb 2006 Posts: 157 Location: Belo Horizonte, MG, Brazil	Posted: Fri Jan 18, 2008 11:37 pm
	Quote Good job, maybe you now could put some more action onto it and background music... The suggestion about the background music made me remember something: I can't make the VDP interrupt work with the C compiler. It gets called, the routine runs, but the execution never returns to the main program, the interrupt just gets called over and over again. Strangely enough, the pause interrupt works with no problems, and it's coded almost the same way. For those who may want to take a look at it, the interrupt handling code is on line 66 of sms_crt0 asm, on the compiler's lib directory. Just enable VBL interrupts, and there it goes crashing... =P Quote If the rotation has to be a transition, why not make it so, by using some kind of low-tech Powerpoint transition? A slide looked bad, how about a wipe or "blinds" transition? Mm... no, I don't think it would look very good in this case, though it would surely look nice on a intro screen. Quote Unless you are going to make a propper turn or transition effect don't bother at all. Adding cheap effects to a cheap turning method is not the recipe for success. My suggestion would be keep the turning as is, nice simple 90 degree turns at a time. Get rid of the perspective effect, it doesn't work, and unless you radically change your engine its not going to work. Well, thanks for the suggestions. Quote Also don't try and make a game based around an engine, make the engine based around the game. Decide first exactly what genre your gunning for and a rough outline for a possible gameplay mechanic. I'm actually trying to do both at the same time. Sometimes, the engine can inspire a game, and vice-versa. But my original idea was either doing a sci-fi third person shooter with some RPG elements, or a first person roguelike, but I'm always open to suggestions. Anyway, here's a new version. I tried to add an enemy, but the engine slows down noticeably when it's present on screen, even after speeding up the perspective calculations. The enemy's sprite also looks corrupted because it's being rendered at the wrong size, but I didn't bother to fix it, yet. Next version, I'll try an RPG battle engine, instead. maze3d-2008-01-18.zip (41.15 KB) Maze3D 2008-01-18 (alpha)

haroldoop Joined: 25 Feb 2006 Posts: 157 Location: Belo Horizonte, MG, Brazil	Posted: Tue Jan 22, 2008 12:20 am
	Well, here's a new version, going back to the first person engine, and beginning implementation of a RPG-styled battle system. The green "things" you see on the screen are supposed to be enemies. Once implemented, it'll be the old traditional game mechanics: The player will walk around for a while, and then, suddenly the enemies will appear in front of him, and then the game will enter battle mode. As can be seen, there are only two enemies on screen. That's because of the 8 sprite per line limit, even though, so far, little less than one third of the maximum sprites per screen are in use. Later, I intend to experiment with combining sprites and backgroud tiles to get around this limit. Adding some flying enemies would also help getting around this. =P maze3d-2008-01-21.zip (40.88 KB) Maze3D 2008-01-21 (alpha)

Disthron Joined: 09 Dec 2007 Posts: 18	Posted: Sat Jan 26, 2008 12:58 pm
Disthron Joined: 09 Dec 2007 Posts: 18	Hay, this looks really cool. I hope you continue on with it.

haroldoop Joined: 25 Feb 2006 Posts: 157 Location: Belo Horizonte, MG, Brazil	Posted: Sun Jan 27, 2008 2:38 pm
	Quote Hay, this looks really cool. I hope you continue on with it. Don't worry, it will be put on ice for a while, until I do something for the PDROMs coding competition, then I'll get back to it.

jpx072 Joined: 08 Feb 2008 Posts: 69 Location: Slovakia	Posted: Sat Feb 09, 2008 10:06 pm
jpx072 Joined: 08 Feb 2008 Posts: 69 Location: Slovakia	I love it!!! It reminds me of Dungeon Master. Oh where are those dungeon times...

Shiru Joined: 08 Oct 2006 Posts: 35 Location: Russia, Moscow	Posted: Mon May 19, 2008 8:38 pm
	Sort of offtopic. Sprite-based 3d engine can be used to make somewhat playable Wolfenstein 3d-like action game. That was proved by 'Doom' demo made in 1996-97 for russian ZX Spectrum clones (check video on YouTube). It uses sprites to display walls, objects, and even floor texture; allows to rotate and move in 32 directions; has some different wall textures and 6 types of enemies per level (up to four on screen). Works on 3.5 MHz Z80, 128K RAM. Game wasn't finished, but playable demo with one level, some enemies and weapons was released. Advance of Spectrum that it has 6K video memory in Z80 address space, so it can do software render faster than SMS, but maybe similar tech can be used on SMS too.

haroldoop Joined: 25 Feb 2006 Posts: 157 Location: Belo Horizonte, MG, Brazil	Posted: Thu May 22, 2008 1:46 pm
	Yes, I saw that one, and also Wolfenstein 2004, by the same guys, if I'm not mistaken (there's source for that one available, but I haven't been able to read it), and also a similar game for the TI-85 (For which there's z80 asm source available too, and that one is readable (well, it's not commented, but you can read it)). I also studied the possibility of implementing a raycasting engine heavily based on pre-calculated tables, but I didn't get to the coding stage. For those who are interested on the 3D-dungeon project: I haven't quit yet, I just have been on a severe lack of free time lately... =P

Shiru Joined: 08 Oct 2006 Posts: 35 Location: Russia, Moscow	Posted: Thu May 22, 2008 3:20 pm
	haroldoop wrote Yes, I saw that one, and also Wolfenstein 2004, by the same guys, if I'm not mistaken I'm one of guys behind the Wolfenstein 2004 (I made level editor, some gfx, etc). We are not related to authors of 'Doom' at all. Last demo of Doom was released in 1997, Wolf project was started in 1996 and, with pauses for years, finished in 2004. Wolf'2004 uses raycasting, but slightly different from classic one, which was used in original Wolf for PC (it has 'paper' walls instead of 'cubes', for example). Sources of Wolf'2004 can be converted in plain text, but they heavily relies for features of Alasm (advanced native ZX assembler). Main author of Wolf'2004, Alone Coder, speak english and can answer to questions if needed (PM me for contacts).

haroldoop Joined: 25 Feb 2006 Posts: 157 Location: Belo Horizonte, MG, Brazil	Posted: Mon May 26, 2008 2:20 am
	Whoops... =P Sorry for the mistake, and thanks for the info. :)

Forums

View topic - 3D Dungeon