#Any way to billboard tiles?

62 messages · Page 1 of 1 (latest)

rugged heart
#

u wanna billboard them so the map is facing the camera?

#

or do u wanna billboard individual tiles?

rugged heart
#

any reason you're not using vbos?

rugged heart
#

there are lots of ways to do that

#

but basically for your world blocks, you just need to submit them once and never move or rotate them

#

just rotate the camera

#

the problem is in the process then

#

in those screenshots it looks like youre rotating the blocks as well

#

this is how rotating in my game looks, just rotating around the froggo

#

this is an orthographic projection

#

you wont be able to billboard those individual tiles tho, is the main thing, not for this effect

#

they need to be "in the world"

#

like if you dont want to iterate through a grid and draw individual sprites then you need to submit them all at once as a vbo, without a billboarding shader

#

rewriting the whole buffer isnt that big a deal in most circumstances, like it really depends on how big the vbo is. animating them can be done by packing the frame uvs into the vertices but you can also submit individual blocks that need to animate (i know u dont have real blocks but they pretty blocky lookin haha) separately. you can also keep a version of the world vbo open as a raw buffer and peek/poke new info into specific vertices as need and convert back into a vbo

#

basically you have a vertex buffer, and a raw buffer, and a struct. the vertex buffer is whats submitted, the raw buffer is a copy of that, and the struct contains all the data for each vertex, or triangle, or "block" however you wanna collate that data. the struct would contain the buffer address of a vertex as well as its data, so you could peek-poke into the raw buffer, change things, then swap the vbo out

#

the struct is the catalog, the raw buffer is where the changes happen, and the vbo is how its submitted yeah

#

they are definitely just iterating through things to draw in that video

#

its untenable at any scale bigger than the few blocks in that video

#

like if you step through at video 1 by 1 they are just changing the position of 2d sprites

#

yep. the answer lies in vertex buffers and shaders

#

its the same thing i already said: you batch everything as a single vertex buffer, and edit/submit as changes happen

#

its a lot to learn and take in yeah

#

you can use shaders for all kinds of stuff. like in my game all of my water animation and grass animation is done on static vertex buffers (so not editing or resubmitting, no moving, very fast) using shaders

#

depends on how its moving and why, but absolutely. its common to bake vertex data into a vertex so that a shader can move it instead of it being moved in gml. thats great for gpu particles and things that need to move but not collide

#

so check this out

Capture.PNG
#

that circled number, 70,800

#

that is the number of vertices being submitted in the vertex_submit calls with red dots beside them

#

that is the same as almost 12 thousand draw_sprite calls

#

its moving

#

but its still part of the world vbo

#

same with those cat tails

#

they are actually in the same vertex buffer, and moving differently. instead of re-building 70,000 vertices each frame i use a shader to animate those things

#

it is

#

i just wanted to show how you move vertices with shaders

#

its not that its water, or a cattail, or my game, its just that it illustrates that you can do these things

#

end of the day: if you want the exact effect from the video on reddit but performant, you will need to learn all of these things

#

shaders, vertex buffers, 3d camera, etc

rugged heart
#

here is i guess, a better example of getting that effect without learning all the 3d shits. but still you would have to learn some. imagine it like this:

  • you build a vertex buffer that contains all your sprites (the blocks that are not blocks)
  • you use a custom vertex format that has 4 positions instead of 1 (regular format uses position, color, texture, you want position position position position and color)
  • each position is where that vertex would be based on the camera angle.
  • when the camera changes, you use a shader to move the sprites in the vertex buffer but lerping their current position to their next position
Capture.PNG
#

you would still have to learn to use vertex buffers, because the ground would be like all a single vertex buffer. you would not need to use the 3d camera tho, not really

#

you would also need to math out where the position of each vertex would be based on the fake angle

#

essentially something like this would do exactly what that video does, but performantly.

#

yeah like, mulling it over, you'd still have a lot of work cut out for you in the math department

#

right so lets call each sprite a tile: your vertex buffer is made out of tiles, each tile has 6 vertices. for each of the 6 vertices, you would need to bake their room position based on their angle.

#

if you have a way to get vertex position based on camera angle then youre like already winning the war hah

#

yes

#

make sure you follow the winding order tho

#

one sec

#

you want to write them in this order: ABCDEF so they follow the default winding order funtimes

#

yeah p is the interpolation percent

#

and you would define that by counting frames basically

# 
//setup
transition = 30; //howmany frames the transition should take
count = 0;

//execute
if (switchangles) {
  count += count < transition;
  p = count / transition;
  if (count == transition) {
    count = 0;
    switchangles = false;
  }
}```
#

something like that

#

yes, its passed from gml to the shader

#

as a uniform

#

yes, you want the interpolated value though. the 0 to 1

#

its all good

#

yes

#

yeah so A and B have to be integers (array_uniform_i not _f) and they are to TO and FROM indices. so like if you want to rotate from 45 degrees to 135 degrees then A is 0 and B is 1

#

that would be however you intend to rotate the camera, and it gets passed to the shader using the various uniform passing functions

#

i am about to have to get out of here for a while soon, so yer gunna be on yer own. i would like to stress though, that this is still going to be a slow process of learning a lot of new things. dont try to do it all at once. sounds like you already know vbos pretty good so start by working on custom vertex formats, then move onto the vertex shader and manipulating those vertices using it. then from there go to interpolating between points