Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Geek Culture / 3D maze with sprites (I think I just peed my pants)

Author
Message
C0wbox
17
Years of Service
User Offline
Joined: 6th Jun 2006
Location: 0,50,-150
Posted: 29th Mar 2011 04:20 Edited at: 30th Mar 2011 04:41
I've been copying this thread in Java using Slick2D and it was going quite well until suddenly I seemed to have accidentally created a full Wolfenstein maze in about 250 lines. - I scared myself when that worked.



The maps I'm using are ripped from a 2D game I made in Java and include pickups doors and stuff. - Does anyone have any idea how I'd do a sprite engine ontop of this raycasting maze engine? ?
(Also being able to properly texture the walls would be good too, rather than having a spew of texture down the side.)

But heck, this is further than I thought I'd ever get with a 2D-to-3D engine like this. I imagined I'd need to learn how to write DirectX from scratch to get even close to this. xD

Java version: (v0.01)


Oh there's also another problem; we can't seem to get it to run on a mac. :S

EDIT:
I've recreated the whole program in DBP using exactly the same format and uploaded it for people to compare the 2:

DBP version:


Comparison shots of DBP (left) and Java (right)



Incase anyone wants to play the original horrible 2D game I'm using the maps from, here's a link - It's using javax.swing and java.awt so it really is hideous. xD

Neuro Fuzzy
16
Years of Service
User Offline
Joined: 11th Jun 2007
Location:
Posted: 29th Mar 2011 08:53


That's a really cool method for a faux 3d effect!

C0wbox
17
Years of Service
User Offline
Joined: 6th Jun 2006
Location: 0,50,-150
Posted: 29th Mar 2011 16:13
I know right !

I can't believe I'd never tried it before seeing that guy's thread. xD

Interplanetary Funk
14
Years of Service
User Offline
Joined: 19th Apr 2010
Location: Ipswich, United Kingdom
Posted: 29th Mar 2011 16:19
Just out of curiosity, how do you actually do it like that? have you written your own 3D pipeline? If so how does it work?

Get on my level
C0wbox
17
Years of Service
User Offline
Joined: 6th Jun 2006
Location: 0,50,-150
Posted: 29th Mar 2011 16:23
Well, I could give people the code if they're generally interested but it quite literally just raycasts out infront of the player and draws a long thin sprite of suitable size and position accordingly.

The only complicated part was coding the raycasts on a 2D array and deciding how I wanted the sprites to be displayed in terms of FOV and quantity.

Neuro Fuzzy
16
Years of Service
User Offline
Joined: 11th Jun 2007
Location:
Posted: 29th Mar 2011 16:31
It's explained pretty well in Cliff Mellengard's thread C0wbox linked to. Especially by these two pictures:
raycasting:

Lower resolution wall:


Interplanetary Funk
14
Years of Service
User Offline
Joined: 19th Apr 2010
Location: Ipswich, United Kingdom
Posted: 29th Mar 2011 16:37
so it calculates the distance using raycasting and then inversely sizes a certain part of the sprite in relation to the distance..?

Get on my level
C0wbox
17
Years of Service
User Offline
Joined: 6th Jun 2006
Location: 0,50,-150
Posted: 29th Mar 2011 16:40 Edited at: 29th Mar 2011 16:44
Yeah - (Well, not a certain part of the sprite - just the whole thing)

1 sprite per ray

The basis of my engine is this:


Interplanetary Funk
14
Years of Service
User Offline
Joined: 19th Apr 2010
Location: Ipswich, United Kingdom
Posted: 29th Mar 2011 16:43
Ah, so walls are made up of several sprites?

Get on my level
C0wbox
17
Years of Service
User Offline
Joined: 6th Jun 2006
Location: 0,50,-150
Posted: 29th Mar 2011 16:45 Edited at: 29th Mar 2011 16:47
Yeah, you can sort of see that in the first 2 pictures, but I improved the resolution for the 3rd one so much that you can't really tell it's using sprites at all. - That's why I shocked myself when I got it working.

Interplanetary Funk
14
Years of Service
User Offline
Joined: 19th Apr 2010
Location: Ipswich, United Kingdom
Posted: 29th Mar 2011 16:46
Cool, go you!

Get on my level
Cliff Mellangard 3DEGS
Developer
18
Years of Service
User Offline
Joined: 20th Feb 2006
Location: Sweden
Posted: 29th Mar 2011 21:31
Quote: "Does anyone have any idea how I'd do a sprite engine ontop of this raycasting maze engine? ?"

If you mean for enemys so do you simply use sprite priority according to its distance and then use an similar method as the walls to get the enemy position.
Time to go back to my dbp version
Quote: "(Also being able to properly texture the walls would be good too, rather than having a spew of texture down the side.)"

Thats where iam stuck right now
They dosent want to aligne correctly and gets screwed when you move up close.
C0wbox
17
Years of Service
User Offline
Joined: 6th Jun 2006
Location: 0,50,-150
Posted: 29th Mar 2011 21:48
Yeah the problem with the sprite engine isn't that I can't draw them in the right position but it's that they'll stick out around walls because it'll only cast a ray between the centre and the player whereas the sprite is much wider (unless I want a game full of stick people xD)

As well as this there's the issue that the wall raycasting works by returning the distance from a point in a direction. But this will mean that enemies may not necessarily be hit by a raycast under that method. So I'd need a separate raycasting engine that checks all sprites against the player's position and only draws them if there is a clear path. - That sounds simple enough but I don't know how to test a ray that goes from a point to another point. (Only how to test a ray that goes from a point in a direction )

I literally have no idea how texturing works in actual polygon engines to even begin to guess at how I'd texture the walls in my engine. xD

Interplanetary Funk
14
Years of Service
User Offline
Joined: 19th Apr 2010
Location: Ipswich, United Kingdom
Posted: 29th Mar 2011 21:53
do a ray cast, if it hits, do 2 extra raycasts to each side of the sprite to actually determine wether anythings in front.

Or as Cliff said, draw the sprites in order of distance from furthest to closest?

Get on my level
C0wbox
17
Years of Service
User Offline
Joined: 6th Jun 2006
Location: 0,50,-150
Posted: 29th Mar 2011 21:58
@ PlanetaryFunk
Yeah the trouble with that first idea is that that's basically what's already being done. - It's doing about 300 raycasts but there is still always the chance it could miss a sprite - causing a flickering effect as you move.

And the drawing the sprites in order of distance doesn't help. - That'll ensure they appear correctly in terms of each other but not the walls. - I can only draw the sprites before or after the walls get drawn, I can't integrate it into that procedure without treating the sprites like wall segments of a different texture.

I'll have a go and see what I can do with some of these ideas once I've recoded it in DBP for Cliff.

Cliff Mellangard 3DEGS
Developer
18
Years of Service
User Offline
Joined: 20th Feb 2006
Location: Sweden
Posted: 29th Mar 2011 21:59 Edited at: 29th Mar 2011 22:03
Quote: "Yeah the problem with the sprite engine isn't that I can't draw them in the right position but it's that they'll stick out around walls because it'll only cast a ray between the centre and the player whereas the sprite is much wider (unless I want a game full of stick people xD)"

You could also simply make an large collision box around the enemys ,so that they cant get to close to the walls so this happens.
By doing this so will you get an automated extra distance to the enemy and the closest wall.
If you look closely on the old wolfenstein engine so do they seam to use an box in the same size as the walls?
Quote: "I literally have no idea how texturing works in actual polygon engines to even begin to guess at how I'd texture the walls in my engine. xD"

Thats the main pain for me right now also
Iam working on an idea to draw extra segments on top with the right texture order.
As we know where the wall block starts and ends

EDITED...............

Quote: "And the drawing the sprites in order of distance doesn't help. - That'll ensure they appear correctly in terms of each other but not the walls. - I can only draw the sprites before or after the walls get drawn, I can't integrate it into that procedure without treating the sprites like wall segments of a different texture. "

Sorry i missed this part
Probably why your engine is alot faster then my version.
i have planned to do this from the beginning
C0wbox
17
Years of Service
User Offline
Joined: 6th Jun 2006
Location: 0,50,-150
Posted: 30th Mar 2011 00:22 Edited at: 30th Mar 2011 00:27
Quote: "You could also simply make an large collision box around the enemys"

Na that won't cut it either.

Think about this scenario:


The blue cross represents the player, the green line represents the sprite and the red cross represents the centre of the sprite.

The sprite is nowhere near a wall but the player should still be able to see part of the green line.

But with the current method I'd be using to determine if there's something in the way of the sprite it'd be testing a line between the blue and red crosses. So in this picture, the sprite wouldn't be shown but should be being shown.

I also recreated the whole code in DBP.

Here's the code from Java:

And here's what it looks like in DBP:


In Java I can easily get it up to 500FPS, but in DBP it can barely reach 60FPS most of the time for me.

Attachments

Login to view attachments
Interplanetary Funk
14
Years of Service
User Offline
Joined: 19th Apr 2010
Location: Ipswich, United Kingdom
Posted: 30th Mar 2011 00:57
You could draw the walls last?
use some clever raycasting to decide wether the wall should be in front of the sprite or behind it and then paste the sprites onto a bitmap and then the walls (not pasting them over sprites when the shouldn't) before pasting the entire bitmap to the back buffer? It sounds long and slow, but it's the only way I can think of with your problems atm.

Get on my level
Dark Java Dude 64
Community Leader
13
Years of Service
User Offline
Joined: 21st Sep 2010
Location: Neither here nor there nor anywhere
Posted: 30th Mar 2011 01:10
Wow, would have peed my pants too if i did this! So i understand no 3D objects are used here? (im too lazy to look at the code)

+ =
Ocho Geek
16
Years of Service
User Offline
Joined: 16th Aug 2007
Location: Manchester, UK
Posted: 30th Mar 2011 01:15
awesome... oh it crashed

nvm, you should make a game creating program from this

Ocho Geek - Pretending to be a useful contribution to the forums since 2005
Diggsey
17
Years of Service
User Offline
Joined: 24th Apr 2006
Location: On this web page.
Posted: 30th Mar 2011 01:29
Just treat items as though they are walls but textured. To get texturing just find the distance along the wall which the ray hit and use the matching slice of the sprite for the item.

To get the depth right store the depth of the walls in an array as they are drawn and then draw the item after, making sure to only draw it over slices which are closer than the depth in the array. (Effectively a 1D depth buffer)

[b]
C0wbox
17
Years of Service
User Offline
Joined: 6th Jun 2006
Location: 0,50,-150
Posted: 30th Mar 2011 01:40 Edited at: 30th Mar 2011 01:40
@ PlanetaryFunk
Yeah most of that is what I'll probably end up doing.

@ Dark basic dude79
No 3D objects are being used. Everything you're seeing is made up of cleverly scaled sprites.

@ Ocho Geek
Yeah it will crash if you look outside the map. - The end of the level should be before you get to this point but because I haven't got sprites working yet I haven't implemented gameplay mechanics like this. (You just have to remember to not look down the end of that last corridor otherwise it'll try a raycast that goes out of the boundaries of the BSP array. )

@ Diggsey
I think I get what you mean there, but I can spot a problem that I can't phrase yet. - There may be a resolution to it though if I try implementing this.

@ Everyone
I probably won't be making any more versions in DBP unless someone can magically speed up my code. (I took set sprite image out of each iteration and gained about 10 FPS but it's still waaaaaay lower than Java.)

C0wbox
17
Years of Service
User Offline
Joined: 6th Jun 2006
Location: 0,50,-150
Posted: 30th Mar 2011 03:29 Edited at: 30th Mar 2011 04:41
! First sprite tests:


It works fine for the gate but as you can clearly see I've got a bit more work to do on the keys and cheeses. - Especially given that they're in the wall-rendering pipeline so the minute you see one it removes the wall behind it.

EDIT:
Ok this looks a bit better but as you can see sprites can sometimes clip walls

(It also pastes 1 picture per positive raycast meaning the closer you get the more sprites there seems to be in the same place (all slightly offset of course))

EDIT2:
Well, I think I just peed my pants again. xD

I've nearly got textured walls working. - They're not there yet but I'm closer than I was:


The game actually works as a game now, you can run through the silly mazes collecting cheeses and keys to open doors (giant yellow blocks) and go through the pink portals to advance to the next level.

Java version: (v0.02)


baxslash
Valued Member
Bronze Codemaster
17
Years of Service
User Offline
Joined: 26th Dec 2006
Location: Duffield
Posted: 30th Mar 2011 15:27
This is awesome! Really great to see people doing something different like this!

The movement seems a little jittery but I love the background work here.

I like the cheese, makes me feel like a rat in a maze (assuming that was the idea).

I see your Java skills are coming along too C0wbox

Well done!!

C0wbox
17
Years of Service
User Offline
Joined: 6th Jun 2006
Location: 0,50,-150
Posted: 30th Mar 2011 15:49 Edited at: 30th Mar 2011 18:40
!

Yeah the movement's jittery because you can only be in 1 square on the 640x640 matrix at any time. - You can't be between squares. (It was less jittery in the 1280x1280 BSP array but I felt I was wasting memory with that one.)

! The cheese surprisingly enough wasn't there to imply that, it's just sort of a random object. - The original game, Jmon, had Chzs as pickups just because I couldn't think of anything else so I put them in this too. !

Java (Especially now I've seen it's doing things I'd want faster than DBP xD )



EDIT:
I thought I'd better mention: I'm actually basing this off a game called I.M.Meen (Hence the name I've given it and the gameplay style.)

Cliff Mellangard 3DEGS
Developer
18
Years of Service
User Offline
Joined: 20th Feb 2006
Location: Sweden
Posted: 30th Mar 2011 18:19
Nice to see that you are making progress
Always nice to inspire people

Maybe i will nead to ask you for help later on

Iam currently looking on going away from wall blocks to more flexible line segments

You can make more fun shapes with that
C0wbox
17
Years of Service
User Offline
Joined: 6th Jun 2006
Location: 0,50,-150
Posted: 30th Mar 2011 18:37 Edited at: 30th Mar 2011 18:40
! I got around that but just making the BSP grid fairly detailed (640x640 per map) so I can have solid (geometric) pillars and shapes in my maps that aren't sprites and aren't orthogonal walls:


I can only assist you up to where my engine stands. - So I can sort of get walls textured but it doesn't quite work properly yet. xD

AndrewT
17
Years of Service
User Offline
Joined: 11th Feb 2007
Location: MI, USA
Posted: 30th Mar 2011 21:46
Very cool! I'm not entirely sure, but from your screenshots it looks like you have a bit of a fish eye effect going on--if you want to fix it, go to the snippet of code that draws the sprites based on their distance from you, and change it so that the size of the sprite is determined by the component of the distance that is perpendicular to the view plane. This is usually done by replacing the distance with d * cos(FOV / 2.0), where d is the original distance and FOV is the field of view angle of your camera.

i like orange
C0wbox
17
Years of Service
User Offline
Joined: 6th Jun 2006
Location: 0,50,-150
Posted: 30th Mar 2011 22:36
! I might try solving that fisheye stuff later if I get a minute, it's not the greatest concern I have at the moment as I've got sprites that clip walls and textures that scroll as you move. xD



Java version: (v0.03)


Cliff Mellangard 3DEGS
Developer
18
Years of Service
User Offline
Joined: 20th Feb 2006
Location: Sweden
Posted: 30th Mar 2011 23:25 Edited at: 30th Mar 2011 23:27
Quote: "I can only assist you up to where my engine stands. - So I can sort of get walls textured but it doesn't quite work properly yet. xD"

I have actually solved the textureing

Quote: "textures that scroll as you move."

You nead to know where the block face that is being hit starts and where the ray hits!
And then do you simply ray hit cord - block face cord.
and your textures will not scroll anymore.
Its really simple if you use linecast!

I like your pillars.
C0wbox
17
Years of Service
User Offline
Joined: 6th Jun 2006
Location: 0,50,-150
Posted: 31st Mar 2011 00:06
D:

I'm glad you can understand all the texturing ray block coord stuff. xD I've fried my brain getting as far as I have. - It may be a while before my engine reaches the same point yours is at. (I'm concentrating more on sprites and gameplay elements now.)

I like my pillars too. - They're geometrical, not sprites.

Cliff Mellangard 3DEGS
Developer
18
Years of Service
User Offline
Joined: 20th Feb 2006
Location: Sweden
Posted: 1st Apr 2011 00:48
Cowbox!

I recently learned how you get rid of the fisheye effect!

rays distance * cos(rays angle)

As simple as that
C0wbox
17
Years of Service
User Offline
Joined: 6th Jun 2006
Location: 0,50,-150
Posted: 1st Apr 2011 01:48 Edited at: 1st Apr 2011 01:51
Well I'm afraid that doesn't work.

So it can't be that simple.

Previous raycast code:


New raycast code:


It just makes the renderer and lighting go all loopy n weird.



EDIT:
Oh and following AndrewT's advice on making it d*cos(fov/2) nothing changed.
(FOV is 60 so I just put ray=ray*Math.cos(Math.toRadians(30)); and it looks exactly the same as it did beforehand. )

AndrewT
17
Years of Service
User Offline
Joined: 11th Feb 2007
Location: MI, USA
Posted: 1st Apr 2011 02:23 Edited at: 1st Apr 2011 02:23
I'm not sure what I was thinking when I made my original post, but there's a mistake in it. For the angle, you don't actually want to use the field-of-view divided by 2; rather, you want to use the angle between the column and the view direction. You can obtain this angle with:

(atan(2 * (colX / screenWidth) - 1.0) * FOV) / 90.0

Where colX is the column of pixels you're currently drawing (or the x-coordinate of the sprite, if you're drawing sprites), screenWidth is the width, in pixels, of the screen, and FOV is the field-of-view angle. If you want to know how I derived that then just ask, but it should work.

So, when you're drawing a column, rather than using your original distance, use that distance times the cosine of the value above.

Sorry for the confusion.

i like orange
C0wbox
17
Years of Service
User Offline
Joined: 6th Jun 2006
Location: 0,50,-150
Posted: 1st Apr 2011 03:25 Edited at: 1st Apr 2011 03:26
D:

Ok well, I tried that but it changed absolutely nothing. xD

I was surprised it still gave the same results actually - that's a lot more complexity per raycast for not a lot of difference.



AndrewT
17
Years of Service
User Offline
Joined: 11th Feb 2007
Location: MI, USA
Posted: 1st Apr 2011 04:09
atan() does not take radians as input--it doesn't take angle measures at all, for that matter, so there's no need for the radian conversion. And, assuming that it returns radians rather than degrees, you don't need to convert the result to radians either. Aside from that...you are setting the variables colX and screenWidth to their appropriate values, right? If that doesn't work then I'm not sure what's going on.

i like orange
C0wbox
17
Years of Service
User Offline
Joined: 6th Jun 2006
Location: 0,50,-150
Posted: 1st Apr 2011 05:57 Edited at: 1st Apr 2011 06:01
Ah yeah, a silly mistake but I'm afraid it's still not doing anything noticeable with this corrected statement:


(All the Java maths commands work in radians so it's necessary when dealing with something that returns/uses an angle measurement to convert to radians when using it.)

Neuro Fuzzy
16
Years of Service
User Offline
Joined: 11th Jun 2007
Location:
Posted: 1st Apr 2011 07:11 Edited at: 1st Apr 2011 07:15
Quote: "All the Java maths commands work in radians so it's necessary when dealing with something that returns/uses an angle measurement to convert to radians when using it."

soooo then Math.atan() returns radians, right? just replace 60 with whatever float pi/3 works out to be.
xD

C0wbox
17
Years of Service
User Offline
Joined: 6th Jun 2006
Location: 0,50,-150
Posted: 1st Apr 2011 15:36
! My trigonometry isn't that great but doing this doesn't do anything either:

!!!

Cliff Mellangard 3DEGS
Developer
18
Years of Service
User Offline
Joined: 20th Feb 2006
Location: Sweden
Posted: 1st Apr 2011 16:36 Edited at: 1st Apr 2011 17:14
Quote: "Well I'm afraid that doesn't work.

So it can't be that simple."

Could be that we write our renderers completely different also
It seams to work for my renderer so far?

You must remember that the ray angle dosent include the angle of the player but only its angle within the fov that is 30 - center +30.
Where i converted the -30 to +30 on that side!
You only nead its positiv value within the fov range.

I looked around the page where i found the raycast tutorial

And i found an exampel by the author in java
Its an very simple one without collision or textures!
But maybe you could look on that one how he solved the fish eye in his code

java/rayc/index.html
C0wbox
17
Years of Service
User Offline
Joined: 6th Jun 2006
Location: 0,50,-150
Posted: 2nd Apr 2011 02:30 Edited at: 2nd Apr 2011 03:17
I don't know for sure if our renderers are different but I was copying yours so I thought mine was at least similar to yours. xD

D: That sounds all complicated now. xD - I'll have another play with it eventually if the fisheye starts to bug me.



In the meantime I decided to improve my map editor and start making a game with the engine:

Activation


It's basically the same game engine as IMBad but it supports diagonal walls & square pillars, has different sprites, has an easier-to-use map format (so you can just open them in notepad and edit to your hearts content) and supports inside and outside environments.

Activation: (v0.01) - Only works on Windows32bit for some reason


Controls:
WASD - Move
Left/Right - Look (I'll add mouse look later)
Up - Sprint (I'll add shift later)
LCtrl - Crouch (I'll add RCtrl later)

Cliff Mellangard 3DEGS
Developer
18
Years of Service
User Offline
Joined: 20th Feb 2006
Location: Sweden
Posted: 2nd Apr 2011 03:22
Quote: "In the meantime I decided to improve my map editor and start making a game with the engine:"

You are at least trying to make an game out of your raycaster engine

Iam constantly trying to improve the renderer and getting stuck with that.
Neuro Fuzzy
16
Years of Service
User Offline
Joined: 11th Jun 2007
Location:
Posted: 2nd Apr 2011 03:38 Edited at: 2nd Apr 2011 03:41
Quote: "ray=ray*Math.cos(Math.toRadians((Math.atan(2*(colX/screenwidth)-1.0)*(Math.PI/3.0))/90.0));"

no no no no no! Math.atan RETURNS RADIANS. You're converting radians to radians!

ray=ray*Math.cos(Math.atan(2*(colX/screenwidth)-1.0)*.66666666);

[edit]
so your FOV is 60 degrees, that's pi/3. The value you're dividing by is 90 degrees, which is pi/2. (pi/3)/(pi/2)=2/3, so you just multiply by 2/3.

I have no idea how that was derived, but i know that you don't have to be doing any conversion between radians and degrees! If all the trig functions use radians, then use radians for everything, and you won't have to convert!

AndrewT
17
Years of Service
User Offline
Joined: 11th Feb 2007
Location: MI, USA
Posted: 2nd Apr 2011 04:03
The function Neuro Fuzzy just posted should work perfectly, though you'll have to adjust it if you're going to have an adjustable FOV.

i like orange
C0wbox
17
Years of Service
User Offline
Joined: 6th Jun 2006
Location: 0,50,-150
Posted: 2nd Apr 2011 04:17 Edited at: 2nd Apr 2011 04:28
@ Cliff Mellangard 3DEGS
! I've added mouse movement now and along with that, the ability to look up and down! ! - I'm so proud of myself because it appears to work nicer than it did in Doom and DukeNukem - they used some sort of faking method that I thought I was emulating but mine looks quite 3D when I do it; theirs just sorta shifted the screen down. xD

@ Neuro Fuzzy
D: I can't tell what's radians and what not, my trigonometry sucks past determining angles of lines. xD

Nevertheless, I've included that latest formula into the next version (regardless of the fact it still doesn't seem to be doing anything)

Oh and I've had to increase my FOV to 70 now - will that stop things from working?

@ Everyone



Activation: (v0.02)


Controls:
WASD/Arrowkeys - Move
Mouse - Look
Control - Crouch
Shift - Sprint

Cliff Mellangard 3DEGS
Developer
18
Years of Service
User Offline
Joined: 20th Feb 2006
Location: Sweden
Posted: 2nd Apr 2011 04:28
Quote: "I've added mouse movement now and along with that, the ability to look up and down! "

I have also looked a bit on that
Its really simple if you dont have floor or ceiling raycasting.
As you simply only have to move the wall renderers center upp and down.

Thats why they dont have it on doom and duke nukem and only an fake one

Iam planning on doing floor and ceiling rendering later on so it have to wait for me!

But great progress !
C0wbox
17
Years of Service
User Offline
Joined: 6th Jun 2006
Location: 0,50,-150
Posted: 2nd Apr 2011 04:31 Edited at: 2nd Apr 2011 04:40
It's just occurred to me that I could probably get away with just making things look taller. - You don't actually have to go up and down things in modern FPSs for them to be fun. (Yeah sure there's the occasional staircase or slight incline of a road, but if that was omitted would anyone really notice? xD)

Might see if I can make some taller walls to emulate height.

EDIT:
Ok that was quite simple to do but made me dizzy looking at the top of pillars, because things don't change perspective when you look up. xD

It also occurred to me that it might be just as easy to do a voxel engine (i.e. a 2D raycast instead of this horizontal 1D thing we're doing) and do it all properly. xD

Cliff Mellangard 3DEGS
Developer
18
Years of Service
User Offline
Joined: 20th Feb 2006
Location: Sweden
Posted: 2nd Apr 2011 11:32
Quote: "It also occurred to me that it might be just as easy to do a voxel engine (i.e. a 2D raycast instead of this horizontal 1D thing we're doing) and do it all properly. xD"

voxel engines can be extremely cool but eats alot of fps!

Iam also thinking abit about it ! but first must i learn to do a proper wolfenstein engine
Neuro Fuzzy
16
Years of Service
User Offline
Joined: 11th Jun 2007
Location:
Posted: 2nd Apr 2011 12:14 Edited at: 2nd Apr 2011 12:15
why not both?


C0wbox
17
Years of Service
User Offline
Joined: 6th Jun 2006
Location: 0,50,-150
Posted: 2nd Apr 2011 17:06
! Inspirational^

I've updated v0.02 because the mouse movement was horrible on some computers. - It should run fine everywhere now.

Login to post a reply

Server time is: 2024-04-23 18:12:36
Your offset time is: 2024-04-23 18:12:36