LÖVE

substitute541 wrote:Here's my FPS
Nontextured
1. 640x480 : 79
2. 800x600 : 60
3. 1024x768 : 56
4. 1280x1024 : 45

Textured
1. 640x480 : 85
2. 800x600 : 72
3. 1024x768 : 58
4. 1280x1024 : 47


Strange, Textured is faster.. Here are my specs :

1280x1024 Monitor
No Graphics Card (derp)
Windows 7 Ultimate x64
(from memory) ASUS P5KPL-AM-SE Motherboard

coffee wrote:Congratulations. Your raytracer should be probably the lightest engine of this kind in LOVE (Inny's one is also quite light).
It's hard to ran one without heat up my machine but your hardware fingerprint is almost null. Also solid vsynced 60fps in both versions.
Plus your code is so clean (and short) that even a math idiot like myself could learn it easily. Well done.
Don't worry about the stretch bug some quad/math LOVE wizard will certainly help you to solve it.

Gravy wrote:Very nice! It makes much more sense to increment the X distance and the Y distance in the same loop rather than do all the X's and all the Y's separately, as in the earlier raycasting demos that Jasoco and others posted a while back. I've been using raycasting for the lighting in my game, and this should make it a bit quicker.

Jasoco wrote:The more raycasters the better. Let everyone create their own. I love it. Imagine if Ken Silverman decided not to create the Build engine because DOOM was just so awesome. We wouldn't have the superior (To the DOOM engine) Duke Nukem 3D/Blood/Shadow Warrior engine which was capable of things the DOOM engine could never do, and even Quake couldn't do in some ways.

Ken started by creating a Wolfenstein 3D style engine of his own when he was a teenager. Then graduated to the more DOOM-like Build engine later on. YouTube has a lot of really cool videos documenting the history of his engines.
http://www.youtube.com/watch?v=l8tDBg4pfYk


My engine eventually gained floor textures (Aided by Canvas) as well as buggy doors, annoying dumb NPC's that just constantly walk towards you, a map and sprite objects. When I get around to redoing it, it will get even more... eventually. At some point eventually.

Inny wrote:Very neat.

In addition to Lode's tutorial, you probably saw this in your searches as well: http://www.permadi.com/tutorial/raycast/index.html

There's a few good tidbits of info in there, like how to get looking up/down and changing the eyeline (to simulate jumping/ducking). In terms of how it applies to Lode's code, the center line you draw the scanlines from is for "Looking", meaning change that and you can look up and down. The eyeline was a bit more tricky. I have updated code that I probably should refresh my old thread with to demonstrate these features. I was taking my engine towards being an RPG engine though, and gave up when it came to floor/ceiling textures since I couldn't find a reasonable way to do it (even the mode7 style code looked to be way too painful toward the framerate).

What I'd also love to see eventually done is variable height floors/ceilings. Even if we can't quite get to textured surfaces, it'd be nice to see doom/hexen or even RiseoftheTriad style vertical movement. It might make a nice longterm goal for you if you want to take your code past the wolfenstein era.

Jasoco wrote:DOOM would be very possible. Except that floor/ceiling would be very hard as far as I've seen so far. (I had to resort to canvases for floors in my Wolf clone and that's just one plane) Also you'd need to figure out collision with arbitrarily positioned lines.

I did do a lot of research into the histories of DOOM and Wolfenstein back then.

The source code for each is readily available even though it's C.

Inny wrote:RoTT seems like the next logical step, seeing as how it was just the floor on a flat plane, and they emulated staircases and platforms heights through sprites.

See: https://love2d.org/imgmirrur/uTlGG.jpg

Gravy wrote:Jasoco, I remember all the awesome screens you posted of your double-layered raycasting with mouselook. We're still waiting for the final product

scutheotaku wrote:

Jasoco wrote:DOOM would be very possible. Except that floor/ceiling would be very hard as far as I've seen so far. (I had to resort to canvases for floors in my Wolf clone and that's just one plane) Also you'd need to figure out collision with arbitrarily positioned lines.

I did do a lot of research into the histories of DOOM and Wolfenstein back then.

The source code for each is readily available even though it's C.

I've yet to look at the Wolf3D or DOOM source code yet, though I've wanted to. Knowing the era and Carmack, there's probably enough Assembly to make my head spin...

Gravy wrote:Jasoco, I remember all the awesome screens you posted of your double-layered raycasting with mouselook. We're still waiting for the final product

Yes!

scutheotaku wrote: Thanks! I'm really glad it proved helpful for you. I'd love for you to message me a link to an example of your lighting, if you don't mind sharing it

Jasoco wrote:

scutheotaku wrote:

Jasoco wrote:DOOM would be very possible. Except that floor/ceiling would be very hard as far as I've seen so far. (I had to resort to canvases for floors in my Wolf clone and that's just one plane) Also you'd need to figure out collision with arbitrarily positioned lines.

I did do a lot of research into the histories of DOOM and Wolfenstein back then.

The source code for each is readily available even though it's C.

I've yet to look at the Wolf3D or DOOM source code yet, though I've wanted to. Knowing the era and Carmack, there's probably enough Assembly to make my head spin...

Wolfenstein has a little Assembly but is mostly C. DOOM is pretty much all C.

Gravy wrote:Jasoco, I remember all the awesome screens you posted of your double-layered raycasting with mouselook. We're still waiting for the final product

Yes!

Eventually. One project at a time. My failing is taking on too many at once and getting bored or stuck too fast.

Gravy wrote:

scutheotaku wrote: Thanks! I'm really glad it proved helpful for you. I'd love for you to message me a link to an example of your lighting, if you don't mind sharing it

I don't mind sharing at all, but it might be a bit less than you were expecting This is a pared down version, but there is still some unnecessary stuff in there. I'm not entirely happy with how it looks, but as soon as I learn how shaders work, I'm hoping I can make the light appear a bit more natural.

I'm in the middle of implementing a spacial hash, using the tile grid as the buckets. This way I can use the same raycasting technique for shooting, just check all the bounding boxes of every object inside each tile to see if they intersect with the line before moving on to the tile.

Inny wrote:What might make an interesting way to do the floor plane is to start with simulating solid colored polygons. Things like the Zombie Baseball demo show off how to do stuff like this. Having the polygon of the floor tile gives you the visual locations on the screen. With that, you can do the Mode7 techniques and get the scissor accurately to where the tile needs to be drawn, cutting down the number of blits per tile down from 240 to whatever the tilesize is (32?) or some small multiple of it.

Jasoco wrote:You need to have all drawables in one single "draw pool" as I call it in my engine. This includes all wall slices (i.e. all the "rays"), all "things", all enemies, anything that will be drawn should be in this single table. Then you sort the entire "pool" and draw everything. It seems you're only adding wall slices and not "things" as well.

Anything that will be drawn should be sorted. You create (or subsequently replace) the pool table (lol) at the start of the Update loop. Then add each drawable one at a time. Its image and quad, its screen position, its X and Y scale values and any other metadata that should be attached to it for use when drawing like maybe colorization or darkness (If you want to add "fog" or "darkness" for distant places.) values. Anything. Also, when adding to the pool, make sure to give each one a "type" so you can handle it later when doing your draw pass.

Do you know how to calculate the screen location of "things" in your view? It will be important for when you want to have other stuff like enemies. Some Pseudocode:

Code: Select all

local dx = THING.x - player.x
local dy = THING.y - player.y

local dist = math.sqrt(dx*dx + dy*dy)

local spriteAngle = math.atan2(dy, dx) - player.rotation_angle

local size = viewDist / (math.cos(spriteAngle) * dist)

local x = math.tan(spriteAngle) * viewDist
local left = (screenWidth/2 + x)
local top = ((screenHeight-size)*player.eyeHeight)

local dbx = THING.x - player.x
local dby = THING.y - player.y

local blockDist = dbx*dbx + dby*dby
local z = -math.floor((dist-.5)*10000)

Might not be completely useful. I had a lot of custom stuff in my project. But it should show you the correct math.

In my engine I had implemented darkness values so far off objects and wall slices would be darker than closer ones. I also made it so any object could be illuminated which would make it show up 100% brightness no matter what. Before I got stuck I had plans for adding pre-calculated lighting effects and other cool things. I can't wait to go back to it really. But not until I am done with my current project. One at a time, Jason.

--"thing" loop
	for x = 0, thingCounter, 1 do
		--convert x,y position to polar coordinates
		local myAngle = math.atan2(thingY[x], thingX[x])
		
		--if I'm inside player's vision cone
		if ((myAngle >= angle1) and (myAngle <= angle2)) then
			--calculate distance to player
			local dX = posX - thingX[x]
			local dY = posY - thingY[x]
			local dist = math.sqrt((dX * dX) + (dY * dY))
			
			--add self to draw table
			drawTable[currentDrawTableID] = {id = x, drawType = "thing", distanceToPlayer = dist}
			currentDrawTableID = currentDrawTableID + 1
		end
	end