A Question about WebGL and its Implementation in C3?

  • Use a filesharing service like:

    gofile.io

    sendgb.com

    Then post a link.

  • Ah, ok. Was not sure on how we are suppose to do it here on the forum.

    Ok! Here it is!

    Im using the latest Release r203 beta, so make sure to use that!

    This is one way of doing it. You can optimize it even more, if you only use the billboard sprites in the editor. Make 2 new variables "Start_x" & "Start_y" and do the translation from those.

    Even better, check an area in front (cone), or around the player and create the billboard sprites from an array. Sorry, if i hijacked this. Just wanted to show you, one way of doing it! :).

    For some reason, i love billboard sprites! Maybe because i played wolfenstein and other raycaster games when i was young.

    Updated and optimized. Should run even faster now!

    srv-file16.gofile.io/download/eeYlNg/Billboard%20sprites.c3p

  • Ormus Thanks for the great example, very nice. I don't think this hijacking the thread too badly, your example is not webgl, etc. but it's definitely in the spirit of the visuals from the example presented earlier in the thread.

    I also like the billboard style, probably for the same reasons! Going further I also had fun reading this book, which is more about the Doom engine, so it's more about perspective quad render, but the monster sprites are all billboard.

    amazon.com/Game-Engine-Black-Book-Doom/dp/1987418433

    I did not get the Wolfenstein book, but now I think I will based on the fun of this thread :)

    amazon.com/Game-Engine-Black-Book-Wolfenstein-ebook-dp-B0768B3PWV/dp/B0768B3PWV

    Also - would using Z elevation provide any benefit here? Simplification? Other effects?

  • Thank you for your kind words! :). Yea i love the older engines for sure! I think it's partialy because it's pixel art, which i love too.

    I have read that doom book, well looked through it. Some of it i get, some...not so much.

    You can do the same technique for the billboard sprites, with the drawing canvas polygons! Since it's just translating 2d points to the screen!

    But the drawing order has to be solved, since you cant sort by z, with the drawing canvas. Either use painters algo, or some smarter sorting system...

    Anyway, i don't like when people are against 3d, or pseudo 3d with construct! 3d engines are built from scratch! We have "scratch" plus more tools, thanks to construct 3!

    Hm, i dont think so. The z sorting in system seem to be very fast! Sure, one can add effects, but it will bring performance down, of course. But you would seldom have 1800+ billboard sprites on screen at one time!

    Obviously, one can't go as deep with the optimization...still, it's soo fun to tinker! I love construct! Thank you Ashley!

  • Eeek the 2d sprites ate my ram in the editor.

    Maybe do some startup spawns instead.

    Runtime looks good tho.๐Ÿ‘๐Ÿฝ

  • Oh? That's strange...do you have an older computer by chance?

    Thank you! ๐Ÿ™‚

  • Lil bit.

  • Ah ok :). Well like i said, you can always create the billboard sprites from values in an array, check an area around or front of the player. In other words, create only billboard sprites on the fly.

    This is sort of like a stress test.

    I have done raycasting engines with billboard sprites many times, and never came close to that many sprites per level! Then you can even add effects, and what not! ๐Ÿ™‚

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • This looks awesome! I can't wait to try it out, thanks so much for the input!

    I think in terms of efficiency it might be a plan to do sprite pooling... so create however many sprites you need/system can handle ( do some testing for lower end systems ) at runtime, and then use your idea of a cone of visibility ( also known as the camera's frustum ) and then when a sprite is out of view, move it to the furthest new point in the frustum that needs a sprite

    That way you've always got the same number of sprites operating at once and thus are able to plan for cpu usage in other areas :) either way I'm stoked to try this out!!

  • Thanks! Anytime!

    Yes, precisely! You would probably not have 1800+ sprites on the screen at one time. I have tried the array approach with a raycasting engine, and i could actualy have a 4000x4000 array (creating walls, and sprites in front of the player, at runtime. No problem. It took a couple of seconds for construct to load everything in, but when it did, it ran smoothly! :)

    If you have a huge array, remember array.at(). That will give you alot of performence..."nobody" would want to loop through a 4000x4000...anything XD

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)