SABRE - (Stable Actor Based Raycasting Engine) - UPDATES!

[lcl]

Hello forums!

This is SABRE,
a Stable Actor Based Raycasting Engine, which I have built on mcveighja's
gefox - textured raycasting engine. Thanks to him for sharing his codes!

SABRE is a raycasting engine, which is built especially for Game Editor.
It is optimized to run as smoothly as possible, and the current version runs
at stable 32 frames per second with no problems.

I had to make some compromises between quality and stability and as a result
of that, the walls don't look all that nice when the player is near to them.


But with some more distance it looks pretty good.


And well, here's one more comparison:


So, it IS fast. But it does NOT have as good quality as gefox has.

What am I going to do? - I am going to try my luck at building the system again, but this time from scratch,
and make the whole raycasting engine by myself too, so I can finally completely understand how it works, and find the
places for optimization, and also make it more user friendly. My aim is to make a 3D engine for Game Editor, which will be
easy enough for everyone to learn, so that people can begin making games with it. This of course includes adding the possibility
of having moving actors (enemies) in the 3D world. And more.

DOWNLOAD:

SABRE.zip

(290.52 KiB) Downloaded 3849 times

UPDATES:

• I have started the work with SABRE 2.0 and the basic raycasting system is now ready
• The world / level editor is under construction & making decent progress:
  (More info about the editor can be found from the 19th post in this topic: viewtopic.php?f=6&t=12644&p=90376#p90376)
• Update about sprite/object drawing:
  (Link to the post for more information: viewtopic.php?f=6&t=12644&p=93180#p93180)
• Video about SABRE updates
  
• Another update video, view bobbing and multiple storeys
  
• Update video showing the (old and cancelled) world editor in action!
  
• Update video with a nice test map + strafing!
  
• Update video about mouse look!
  
• First video of the new World Editor!
  

GOOD NEWS:
(The 12th post in this topic: viewtopic.php?f=6&t=12644#p90199)

MORE GOOD NEWS (about mouse look!):
(Direct link to the message in this topic: viewtopic.php?f=6&t=12644&p=91744#p91744)

EVEN MORE GOOD NEWS (about mouse look!):
(Direct link to the message in this topic: viewtopic.php?f=6&p=93138#p93138)

NEWS (about floor and ceiling + SABRE template):
(Direct link to the message in this topic: viewtopic.php?f=6&t=12644&p=98054#p98054)


Please download and give me feedback!

And as the last reminder I want to once more say that the basic engine itself is made by mcveighja,
I just made some changes to it to make it run faster. The graphics in SABRE are also the same as the ones mcveighja used.

- lcl -

[skydereign]

This is very nice. Pretty nice idea splitting it into many frames so you could use draw_from. In terms of the quality going down when you are really close, I'd actually prefer if the player wasn't able to move within a pixel of the actual wall. So giving the player some radius would make it better in terms of movement, and prevent the major quality difference too apparent. Though you probably already have plans to make it more user approachable, I would recommend uses the 2d overview method as a way of rendering levels. That way the user could make a pretty straight forward overview game like normal in gE, and your system would then simply be able to render it, in a 3d context.

[lcl]

This is very nice. Pretty nice idea splitting it into many frames so you could use draw_from. In terms of the quality going down when you are really close, I'd actually prefer if the player wasn't able to move within a pixel of the actual wall. So giving the player some radius would make it better in terms of movement, and prevent the major quality difference too apparent. Though you probably already have plans to make it more user approachable, I would recommend uses the 2d overview method as a way of rendering levels. That way the user could make a pretty straight forward overview game like normal in gE, and your system would then simply be able to render it, in a 3d context.

Thanks skydereign!
Yes, I am going to make the next version be easier to use. That 2D to 3D idea is good, I just have to find a way to realize it.

[Hblade]

Very good job LCL! I'm really amazed at this

[knucklecrunchgames]

Do you think you can make a 3D charater?

[Jagmaster]

I think I remember seeing that raycasting demo a long time ago. And it was waaay slow.

But this new method is so ingenious! How did you come up with the "draw from actor" idea? In the first place, I had now idea drawfrom used less resources than normal putpixel loops. I guess that makes sense, is it because the actor's animation is already in the memory, whereas the bitmap is just being read directly from it's file location perhaps? I had always used drawfrom to make circles in canvas (mainly because I was too lazy to write a sine/cosine algorithm for it), but never knew it had this much advantage.

Anyways, bravo! I look forward to improvements!

[lcl]

Very good job LCL! I'm really amazed at this

Thank you!

Do you think you can make a 3D charater?

No I don't. Raycasting has nothing to do with 3D models.

But this new method is so ingenious! How did you come up with the "draw from actor" idea?

Thank you!
Well, I think the idea came from FeralX's editions of gefox (you can find it from the "Raycasting example source"-topic.) The first one he made was done so that textures were abandoned and he used lineto() for drawing the walls. That was much faster (one just had to change the fps limit of the game to be greater than 16, which was the original gefox's fps limit. I think FeralX didn't notice that himself..) than original gefox, but textures were not supported. He also made another one, where he directly used actors for creating the walls. He had 640 actors on screen all the time and he just changed their animpos. But this one didn't support textures either.

When I was playing with gefox (and FeralX's versions of it) once again (I really do this quite regularly ) I remembered how I used draw_from() (combined with SendActivationEvent() ffor changing the font actors animpos to the correct letter) in my newest version of lclOS to draw the text to the screen. And well, then these ideas just merged in my head (it was already quite late, so I think my head was fuzzy enough to come up with that ) and then I think I just got lucky. I tried realizing my idea on original gefox, and all just went right and it worked!

In the first place, I had now idea drawfrom used less resources than normal putpixel loops. I guess that makes sense, is it because the actor's animation is already in the memory, whereas the bitmap is just being read directly from it's file location perhaps?

I think it is that the actors animation is already in memory, and of course that one has to only use draw_from() as many times as the screen is wide, where with pupixel one needs to also call it for every single pixel on those vertical lines, so that is much more function calls than with draw_from().

But to be exact, the original gefox is not constantly reading the texture data from the file. It does that at the beginning, but then draws the pixels based on the data in the array where the textures have been stored.

Thank you all! I am already working on version 2.0! =)

[Hblade]

In version 2 what are you doing? Are you planning on adding a gun in or something?

[lcl]

In version 2 what are you doing? Are you planning on adding a gun in or something?

Information about version 2 is at the first post, in UPDATES.

UPDATES:
- I have started the work with SABRE 2.0 and the basic raycasting system is now ready
- The next thing to do is to create an overview editor which can be used to create a game,
which SABRE 2.0 then renders to 3D.

What I mean with "basic raycasting system is now ready" is that, as I said earlier in that post, I wanted to make the raycasting by myself, so that the whole code is mine. And that's now done.

And LOL, a gun isn't a priority when I'm building a raycasting engine for anyone to use. This isn't a game. It's going to be a game engine inside Game Editor. As I said, in version 2 I am going to develop it to be more user friendly, so that people can actually use it to make games!

And when SABRE is ready, I will make a game with it to show people how to use it to create a game.

[Lacotemale]

This is some really amazing work man!

In the future will it be possible to have a floor texture?

[lcl]

This is some really amazing work man!

Thank you! =)

In the future will it be possible to have a floor texture?

This is actually a very good question.
I am not sure how much it will slow down the raycasting process if there is also floor and possibly a ceiling too.
I have to try adding them.

[lcl]

Sorry for double post, guys.
I just have some REALLY GOOD news.

I have found a way to make the graphics look a lot better, nearly without affecting the framerate at all!
All one has to do, is to multiply the height of the texture images. From 64 to 128, 256 or even to 512. (2x, 4x, 8x)
The more you multiply the better it looks. But multiplying too much begins to slow down the game again.
Here's a pair of screenshot comparisons between the quality of 64 and 256 height textures.


Now this is something that gives the developer a pair of great chances.

First thing is that when your textures get more vertical size, they get more pixels -> the textures can be more detailed!

And the second thing is that if one adds different sized graphics to the game (like 64, 128, 256 and 512) and lets the game user choose
the best for their computer, it is possible to make the game run fast with every computer around by just changing the quality of graphics used in the game!

One more thing that goes to that same category is the fact that with SABRE, it is very easy to export your game in different resolutions.
All you have to do is to change the resolution and then change the "screenWidth" and "screenHeight" to match the resolution (and resize the "screen"-canvas actor). SABRE will then draw the game in the
desired size with no problems. Logically wide resolutions are more demanding for the game, simply because more needs to be drawn. But if a user of the game has a problem
with the game running slow in his resolution, he just has to change the graphic settings! Imagine, you can easily port your game in, let's say 10 different resolutions, let the
user choose which one he wants to use, and also let him balance the smoothness of the gameplay with the graphical look of the game.

Sounds professional, huh?

[Jagmaster]

That's a pretty good result. So one would only have to stretch the image after he's done making it in order to import it into sabre? How would it look if an image was drawn at 64 * 256 and then used, would stretching occur?
I'll be following this pretty closely, it'll be exciting when it's finished.

Sabre is such a good acronym btw
~Like a Jedi
o=E[=========>
^ a liiiiightsaaaaaabre lawl

[lcl]

That's a pretty good result. So one would only have to stretch the image after he's done making it in order to import it into sabre? How would it look if an image was drawn at 64 * 256 and then used, would stretching occur?
I'll be following this pretty closely, it'll be exciting when it's finished.

Sabre doesn't stretch anything on its own, it just uses the graphics you give it. And when I was searching for ways of getting even better graphics, I found out that the textures' width doesn't have to be limited to 64.
So, the next version of Sabre will support textures of all size. They can be whatever sized one wants them to be. And most importantly, textures can be square shaped (like 256 * 256, or 512*512 or what EVER you want) now. That makes it easier to create the textures and it also makes them look better. If you want to see what Sabre 2.0 looks like in its current stages, see the video in the first post.

Sabre is such a good acronym btw

That's good to hear, you don't know how stressed I was about whether it was good or not..

~Like a Jedi
o=E[=========>
^ a liiiiightsaaaaaabre lawl

COOL DUDE! :LOL:

[Jagmaster]

Ah, I see. I saw your video in the first post, and everything looked pretty sweet.

Sabre is such a good acronym btw

That's good to hear, you don't know how stressed I was about whether it was good or not..

Why wouldn't it be? there are so many cool things associated with sabres!

You or someone should make a game called Sabre with the Sabre engine. Some kind of dungeon crawler.

I was thinking about the floor/ceiling. It seems in your demo that the canvas erases with solid black. Would it be easy to erase that with a transparent color? That way, one could add a new canvas underneath and add some mode 7 code to give a cool ceiling affect (or maybe you'll figure out a way to do it all in one canvas, that would probably be better). If not, at least one could change the color of the ceiling / floor.