How to create a 3d dungeon crawler (WIP)

[xela]

In either case, I do not believe that we should be getting lower fps in Ren'Py than in pygame using the same logical design and yet, I get a steady 60 FPS in pygame and 8 - 15 using the same resources in Ren'Py. Such a difference is suspicious and unless otherwise reasonably explained, I have my doubts about the current "Renpystein" engine as a design in general even if you say that they "at core the same".

I don't really want to dive too deep and figure out what happens there line by line but a difference is plainly too much... I managed to improve it slightly but it's still a farcry away, if they are really the same, I want to know why our fps are so sh!tty

===>
A full 1280x720 image cropped vertically into 1 pixel wide scanlines with each being transformed as fast as possible runs at 15 - 25 fps which is still somehow better...

===>
I looked at them both, they are practically the same code copy-pasted

[Ryue]

In either case, I do not believe that we should be getting lower fps in Ren'Py than in pygame using the same logical design and yet, I get a steady 60 FPS in pygame and 8 - 15 using the same resources in Ren'Py. Such a difference is suspicious and unless otherwise reasonably explained, I have my doubts about the current "Renpystein" engine as a design in general even if you say that they "at core the same".

I don't really want to dive too deep and figure out what happens there line by line but a difference is plainly too much... I managed to improve it slightly but it's still a farcry away, if they are really the same, I want to know why our fps are so sh!tty

===>
A full 1280x720 image cropped vertically into 1 pixel wide scanlines with each being transformed as fast as possible runs at 15 - 25 fps which is still somehow better...

===>
I looked at them both, they are practically the same code copy-pasted

Don't forget though that the pygame version uses the pygame code for blitting things on screen while the renpy version uses renpy methods to blit things on screen. Thus there IS a difference.

What I had meant with they are the same is: The mathematics behind it. The pure mathematical algorithm is exactly the same. Although the implementations themselves are different (in my own case when I tried to follow the tutorial behind renpystein my implementation was also very similar to it but I had calculation errros where I never found out the reason......while renpystein just.....worked).

So it could be that the graphic engine there (pygame vs. renpy) makes a difference. If I would have to take a guess I would always guess that renpy is slower as it is optimized for flexibility in usage. Thus I will need to optimize the rendering as good as possible.

In this case the idea of the rescaling came to be. One thing I noticed during tests with renpystein was that the bigger my texture was the slower things got. thus reducing it from 1366 x 768 to 1/2 or 1/3 in scale should bring a speedup (renpystein itself used only 64x64 tiles in its demo).


-------
If I would have to take a guess I would say it is the transforming and cropping that slows things down and not the blitting itself.
If I take http://lemmasoft.renai.us/forums/viewto ... 51&t=32260 I just put dozens of images onto the screen (not optimized by prerendering it!) and it was still
relatively fast. Thus I would rule the blitting out there as speed problem. More the transformation and crop that causes the problems. With that it boils down to optimize that without overloading the memory too much (optimizing there is the easiest way to preload things/prerender things).

Edit: Remembering the old project I had SEVERE problems in terms of speed when it came to transforms (size manipulations to be exact). Which was why I had precalculated/prerendered every single used size of the walls.


Maybe call me insane there but I'm currently thinking if it is possible to combine a few basic ideas from that one project I had there with the raytracing idea.
To create sort of a hybrid there. Back then I had the absolute speed because I just didn't care at all what was in the way, how did the ray travel,.... I "just" blitted what was in front of me and didn't care in the least about angels,.... greatest downside of that approach was that something that was 35° to me looked the same as something that was 25° to me (and 2 images per wall being necessary, 1 front, 1 side). But from the "tracing" side I would daresay it was the fastest things could get.

[xela]

FPS is also being calculated differently, pygame's version could be lying. I am not completely sure what the hell the second crop based on height is for, I removed it and didn't really see a difference...

[Ryue]

FPS is also being calculated differently, pygame's version could be lying. I am not completely sure what the hell the second crop based on height is for, I removed it and didn't really see a difference...

not sure which one you mean but could be that its there to make sure that the image does not extend beyond the view frame.

[Ryue]

So after a long talk with xela I have discarded an idea I got in between as it was not practical (only useable for full 90° turns). The idea is now as follows:
1.) Xela is trying to improve the renpystein version
2.) I myself am going to build things from scratch and explain the steps in here.

So part 3 is: 3 custom engine ported from javascript (and with experiences from renpystein strewn in

So onto
part 4: Implementation

[Ryue]

Part 4: Implementation
The first and most important part here is to decide on an approach. As I'm coming from programming languages where most ppl are used to object oriented approaches (highly object oriented at that) I'm going to go with this approach.
This means I'm trying to define objects for all necessary things.

In the last step we defined objects for the map and map cells (and before that the graphics loaded). Thus we need to look at how ray tracing works to see what steps are necessary.
Raytracing works by sending out a ray for each pixel width of the resolution and trace hits on walls and sprites along the way of it and display the hits.
Thus something like this:

In essence this means we have 3 different things here at work:
1.) The main routine which sends out the traces and registers the hits to display them
2.) The ray itself
3.) The player

This means then that we are having 3 objects:

• Our main engine object which is responsible for controlling the flow of the program
• The ray. It is responsible for moving itself from a specific beginning position and angle along its trajectory. Furthermore it must check if it is has reached its maximum distance or if it can still 'fly'. Thus its single purpose is to have all information necessary about the ray itself.
• The player. This one is responsible for having the players position and facing and moving him around. Thus it has all the information about the player.

As mentioned the main engine is responsible for the program flow. There are now 2 options there to use:
1.) The main engine checks for the hits (thus if a player would hit a wall on a move or a ray hits a wall,....).
2.) The sub classes Player and Ray check for hits.

Personally I think the 1st makes more sense as it makes sure that the sub classes only have informations available that are necessary for themselves.
Thus the main class makes the checks with the help of a method inside the map class.