Terrible Raycaster Performance

Haxe
#1

Hey,

I am currently writing a raycaster based on this article, here, however when implemented in OpenFL, I get horrendous performance, or a crash. The code is available in this gist, here. I understand that software rendering is slow, pixel manipulation more-so, but how can I optimize this to achieve a playable performance?

I have implemented the same code in Kha as well, with “better” performance, I guess.

Any help would be appreciated.

Thanks, G

#2

getPixel, setPixel and fillRect are going to be software operations, so it’s up to the CPU performance of modifying the pixels, then uploading that to a GL texture again before rendering.

How is it working in Kha?

#3

It’s done by using a similar method; getting and setting pixels of an Image which is then drawn. Performance is not terrible, when run on HTML5. How could I speed this up, or what’s the hardware accelerated alternative?

#4

I’d imagine that a single call to setPixels() would be faster than a bunch of calls to setPixel().

#5

The best solution would be to directly apply your bitmap rectangle texture to a polygon mesh (composed of 2 triangles for each of your walls) by directly accessing openGL. That way all the computation would be performed by your GPU.

Using lime.graphics.opengl and lime.graphics.GLRenderContext you can probably achieve what you want but you probably would have to write your own ‘DisplayObject’ class as I don’t think the openfl Sprite or Bitmap class directly expose their GL context object…

#6

Does openfl test html5 -Dcanvas perform better, or openfl test windows -Dcairo?

#7

HTML5 performance is okay, not playable, but okay. I am building with cairo at the moment. Is there anything I could replace the set/getPixel workflow with so it can be usable?

Edit: Cairo build crashes when you run.

#8

Perhaps there is a way to adapt the code into something that would use OpenGL 3D acceleration for the rendering, rather than software. I found this online, which looks similar, although the draw calls are desktop GL, and not GLES-style calls like we use in Lime or OpenGLView

#9

Nowadays using 3D acceleration is faster, than direct pixels manipulation.
If you want to make wolf-like engine, there is 3 ways:

  1. For each vertical column on screen do standard raycast, but draw each column via GPU (basically it will be 1px vertical line with texture). Wolf 3D for iPhone use this way.
  2. Draw entire walls (each wall - one textured quad). It harder to calculate wall coordinates (compared to way #1), but it is faster. I make Gloomy Dungeons 3D using this way, renderer - https://github.com/restorer/gloomy-dungeons-3d/blob/master/src/main/java/zame/game/engine/LevelRenderer.java#L295 , tracer - https://github.com/restorer/gloomy-dungeons-3d/blob/master/src/main/java/zame/game/engine/PortalTracer.java
  3. If your level is small, you can just render everything via GPU. And it will be pretty fast. Also this way you can render any level geometry, not just wolf-like

P. S. Probably way #1 will work well without OpenGL - using Bitmap / BitmapData (which will renders as img on html5 and drawImage() on canvas). Canvas example - http://mobile.zame-dev.org/gloomy-ii/#play , source - http://mobile.zame-dev.org/gloomy-ii/gloomy/js/engine.js (it is plain javascript, but I think you can do similar with OpenFL)

#10

thank you, I’ll take a look at these!