Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bunnymark GL in Jai – 200k sprites at 200fps [video]

youtube.com

Post reply on HN
Print view View original

21–30 of 70 posts

Re: Bunnymark GL in Jai – 200k sprites at 200fps [video]

#21

Post by ArtWomb »

xaedes wrote: post #6

Nice demo! We need more of this approach. You really can achieve amazing stuff with just plain e.g. OpenGL optimized for your rendering needs. With todays GPU acceleration capabilities we could have town-building games with huge map resolutions and millions of entities. Instead its mostly only used to make fancy graphics. Actually I am currently trying to build something like that [1]. A big big world with hundreds o…

I immediately thought of the bullet physics games like gradius, parodius, raidan, r-type.

What made it of course was the art. An army of digital illustrators working by hand to create bitmaps that pop.

One pseudo 2.5d game I'm playing now is Iridion 2 GBA (2003). You can see the care taken with the art design team, pure lovers of the genre ;)

Re: Bunnymark GL in Jai – 200k sprites at 200fps [video]

#22

Post by iliketrains »

chrisseaton wrote: post #20
juancn wrote: post #13

Neat. Isn't this akin to 400k triangles on a GPU? So as long as you do instancing it doesn't seem too difficult (performance wise) in itself. Even if there are many sprites, texture mapping should solve for the taking pixels to the screen part. My guess is that the rendering is not the hardest part, although it's kinda cool.

> Isn't this akin to 400k triangles on a GPU? Is it faster to render two triangles with slightly less area, or one triangle with slightly more area, to draw the same sprite?

Rendering only one large triangle can be faster than two. First one triangle needs less memory, less vertex processing, etc.

Second, modern GPUs render pixels in groups of 2x2 up to 8x8 "tiles". If only one pixel from this group is part of a triangle, the entire group will be rendered. When two triangles form a quad, the entire area along the diagonal "seam" will be rendered twice. The smaller quads you have, the more overhead.

Also see https://www.saschawillems.de/blog/2016/08/13/vulkan-tutorial...

Re: Bunnymark GL in Jai – 200k sprites at 200fps [video]

#23

Post by juancn »

chrisseaton wrote: post #20
juancn wrote: post #13

Neat. Isn't this akin to 400k triangles on a GPU? So as long as you do instancing it doesn't seem too difficult (performance wise) in itself. Even if there are many sprites, texture mapping should solve for the taking pixels to the screen part. My guess is that the rendering is not the hardest part, although it's kinda cool.

> Isn't this akin to 400k triangles on a GPU? Is it faster to render two triangles with slightly less area, or one triangle with slightly more area, to draw the same sprite?

Honestly I'm not sure.

I don't think that at 200k or 400k level will matter much. Math is probably easier on humans if you think about the sprites as rectangular (so two triangles), but you could in principle make each sprite a triangle, and texture map in a shader a rectangular area of the triangle.

Re: Bunnymark GL in Jai – 200k sprites at 200fps [video]

#24

Post by liftm »

Does this work with large semi-transparent objects? (My 10-year-old experience with 2D game engines was that 10k objects wasn't really a problem, unless you were trying to make clouds or fog from ~200x100px sized, half-transparent images. Have a 100 of those, and you'd run at 5 FPS.)

Re: Bunnymark GL in Jai – 200k sprites at 200fps [video]

#25

Post by quadcore »

chrisseaton wrote: post #20
juancn wrote: post #13

Neat. Isn't this akin to 400k triangles on a GPU? So as long as you do instancing it doesn't seem too difficult (performance wise) in itself. Even if there are many sprites, texture mapping should solve for the taking pixels to the screen part. My guess is that the rendering is not the hardest part, although it's kinda cool.

> Isn't this akin to 400k triangles on a GPU? Is it faster to render two triangles with slightly less area, or one triangle with slightly more area, to draw the same sprite?

Pretty sure overdraw / fillrate bottlenecks before vertex processing. Also you could draw that quad using strips which would then amount for only one more processed vertex compared to triangle.

Edit: okay surely with modern architecture there is no pixel write because of some early alpha cut but you still have to fetch the texture to make it so texture fetch (memory) will bottleneck first. I guess.

Re: Bunnymark GL in Jai – 200k sprites at 200fps [video]

#26

Post by quadcore »

Using Goroutines, I also made 10k 2D rabbits wander on a map for 5% of my laptop cpu (they'd sleep a lot admitedly). One goroutine per rabbit, how amazing when you think about it. That's when Go really got me.

edit: oh they do rabbits in the video as well what a bunny coincidence

edit2: the goroutines werent drawcalling btw, they were just moving the rabbits. The drawcalls were still made using a regular for loop, in case you wonder.

Re: Bunnymark GL in Jai – 200k sprites at 200fps [video]

#27

Post by daenz »

It's been awhile since I've done game engine work, but is this impressive? The first thing that comes to mind is they're using instanced rendering. This allows the CPU to only deal with 1 sprite, while telling the GPU to render multiple instances of the sprite, and use a GPU buffer to find each sprite's transformation matrix. All the CPU has to do is update that mmap'ed buffer with new position information (or do something more clever to derive transformations).

Am I missing something that makes the video novel?

Re: Bunnymark GL in Jai – 200k sprites at 200fps [video]

#28

Post by chrisseaton »

quadcore wrote: post #25
chrisseaton wrote: post #20

Earlier quoted context omitted.

> Isn't this akin to 400k triangles on a GPU? Is it faster to render two triangles with slightly less area, or one triangle with slightly more area, to draw the same sprite?

Pretty sure overdraw / fillrate bottlenecks before vertex processing. Also you could draw that quad using strips which would then amount for only one more processed vertex compared to triangle. Edit: okay surely with modern architecture there is no pixel write because of some early alpha cut but you still have to fetch the texture to make it so texture fetch (memory) will bottleneck first. I guess.

By this argument you should higher performance from higher-poly models... which clearly isn't the case?

Re: Bunnymark GL in Jai – 200k sprites at 200fps [video]

#29

Post by quadcore »

daenz wrote: post #27

It's been awhile since I've done game engine work, but is this impressive? The first thing that comes to mind is they're using instanced rendering. This allows the CPU to only deal with 1 sprite, while telling the GPU to render multiple instances of the sprite, and use a GPU buffer to find each sprite's transformation matrix. All the CPU has to do is update that mmap'ed buffer with new position information (or do som…

Nope, I don't think so. The point I see in it is regarding some thought I have about that games should run on intel graphic chipsets. Diablo 3 doesn't for example. I wonder if D2 ressurected does...

Re: Bunnymark GL in Jai – 200k sprites at 200fps [video]

#30

Post by quadcore »

chrisseaton wrote: post #28
quadcore wrote: post #25

Earlier quoted context omitted.

Pretty sure overdraw / fillrate bottlenecks before vertex processing. Also you could draw that quad using strips which would then amount for only one more processed vertex compared to triangle. Edit: okay surely with modern architecture there is no pixel write because of some early alpha cut but you still have to fetch the texture to make it so texture fetch (memory) will bottleneck first. I guess.

By this argument you should higher performance from higher-poly models... which clearly isn't the case?

Oh, let me clear that for you. The trick discussed here is that you can draw a sprite (a quad) using one large triangle. The sprite is just inside it but the triangle has quite some "wasted" surface.
Post reply on HN