22 replies to this topic

[szotyi41]

What I want to know is how I would load a sprite, read it's pixel data, and convert the pixels into walls.

color_get_green(pix); //forest wall

http://kepfeltoltes....ltoltes.hu_.png

Edited by szotyi41, 19 February 2012 - 09:46 AM.

[amiel]

the_color = color_get_green(pix);

Now use the_color variable as your color to draw the 3d walls.

[hit172]

you could also just use d3d_block_draw at each of those positions.... (instead of wall b/c then there is no need for direction)

[Gamer3D]

But that is really inefficiebt, if he wants each pixel to represent a 3D block then he needs a voxel engine similar to minecraft and should look around for some of those examples as well...

For GM, it's probably more efficient to create a model using whatever lets him generate it fastest (blocks would suffice) than to waste time generating a fancy model.

Alternately, consider creating your levels using walls. It'll be faster and easier than this. Also, you can create a sprite from that if you need.

[hit172]

For GM, it's probably more efficient to create a model using whatever lets him generate it fastest (blocks would suffice) than to waste time generating a fancy model.

Just generate one fancy model once (at the beginning of the level)

Alternately, consider creating your levels using walls. It'll be faster and easier than this. Also, you can create a sprite from that if you need.

Then you would need to find adjacent pixels to connect to to find out if the wall is horizontal, vertical, both, or possibly diagonal.

[Buff-Robotix]

Draw the sprite at (0,0)

for(i=0; i<=sprite_width; i+=1)
{
 	for(j=0; j<=sprite_height; j+=1)
	{
      	col=color_get_pixel(i,j);
      	if(col == redValue)
           	instance_create(i,j,redWall);
      	else if(col == greenValue)
           	instance_create(i,j,greenWall);
 	}

}

Although this would be very slow and result in a lot of walls. It might just be better to save their location in an array.
Or you could do a collision map, where you stretch the whole sprite across the map, make it invisible, and have the character collide with the non transparent parts, although, no walls would be drawn then...

RobotiX

Edited by Buff-Robotix, 19 February 2012 - 10:56 PM.

[Gamer3D]

Alternately, consider creating your levels using walls. It'll be faster and easier than this. Also, you can create a sprite from that if you need.

Then you would need to find adjacent pixels to connect to to find out if the wall is horizontal, vertical, both, or possibly diagonal.

I see I have been misunderstood. When making a level, don't make a sprite. Make a list of walls (start and end). Load that.

If you need the sprite, render a line at the base of each wall to a texture, then use that texture. (May need to save to file, load. Not sure)

Yeah Im sorry but Gamer3D that would be just way to innefficient, it would be easier to code yes but would be slow as hell to generate the model and much slower to draw it. Lets say we build a 10 * 10 tile model, your way, at 1 pixels deep.... that would be 100 (blocks) * 6 sides each block = 600 faces * 2 triangles per face = 1200 polys. Now if we were to do it my way the 100 tiles would have two faces (top and bottom) so 200 triangles + 40 edge blocks would have an extra 2 faces which are 2 triangles so my total would be about 300 polys. The model would render 4 times quicker so it would be a waste to model all the faces that are never seen just because it is easier to code it.

Polygons are fast to draw. (In models. Drawing them individually is really slow in GM) Creating models out of blocks would waste few polygons. (look at the example image. Note the large amount of empty space) The advantage to this method is that it will load as fast as possible (This is why I suggested it).

Your methods (Colton and Buff) are going to be VERY slow to load (and with GM8.1 model draw speed, not noticeably faster than drawing a block per pixel).


If there's anything to take away from this post, it's this: He'd be best off by saving his levels as lists of walls, then building the sprite from it if needed.

[hit172]

Alternately, consider creating your levels using walls. It'll be faster and easier than this. Also, you can create a sprite from that if you need.

Then you would need to find adjacent pixels to connect to to find out if the wall is horizontal, vertical, both, or possibly diagonal.

I see I have been misunderstood. When making a level, don't make a sprite. Make a list of walls (start and end). Load that.

If you need the sprite, render a line at the base of each wall to a texture, then use that texture. (May need to save to file, load. Not sure)

Yeah Im sorry but Gamer3D that would be just way to innefficient, it would be easier to code yes but would be slow as hell to generate the model and much slower to draw it. Lets say we build a 10 * 10 tile model, your way, at 1 pixels deep.... that would be 100 (blocks) * 6 sides each block = 600 faces * 2 triangles per face = 1200 polys. Now if we were to do it my way the 100 tiles would have two faces (top and bottom) so 200 triangles + 40 edge blocks would have an extra 2 faces which are 2 triangles so my total would be about 300 polys. The model would render 4 times quicker so it would be a waste to model all the faces that are never seen just because it is easier to code it.

Polygons are fast to draw. (In models. Drawing them individually is really slow in GM) Creating models out of blocks would waste few polygons. (look at the example image. Note the large amount of empty space) The advantage to this method is that it will load as fast as possible (This is why I suggested it).

Your methods (Colton and Buff) are going to be VERY slow to load (and with GM8.1 model draw speed, not noticeably faster than drawing a block per pixel).


If there's anything to take away from this post, it's this: He'd be best off by saving his levels as lists of walls, then building the sprite from it if needed.

He wants to be able to use the sprite as a base. If he were to use your method he would need to convert the sprite into a list of walls using the method that I described above.
What Colton is saying is that why use all of the blocks if you wont be able to see half of the faces (2 adjacent blocks have a 2 faces in the same position that won't be seen anyway) You can do what Colton says and it would be more cpu intensive in the first step to generate a model that has only the visible faces in the model. Or you can do what you say and have it be more gpu intensive every step of the game... take your pick.

[Gamer3D]

He wants to be able to use the sprite as a base. If he were to use your method he would need to convert the sprite into a list of walls using the method that I described above.
What Colton is saying is that why use all of the blocks if you wont be able to see half of the faces (2 adjacent blocks have a 2 faces in the same position that won't be seen anyway) You can do what Colton says and it would be more cpu intensive in the first step to generate a model that has only the visible faces in the model. Or you can do what you say and have it be more gpu intensive every step of the game... take your pick.

As a method for CONVERTING FROM SPRITES, I suggested using a block for each pixel to reduce load time. For GM, this is probably worthwhile (of course, if you save the model, go for a method with better results).
As a BETTER METHOD THAN SPRITES, I suggested saving lists of walls. I did not suggest converting sprites to walls.

[hit172]

Why not write a program to convert that image to a list of walls? then you get the ease of designing the level with the speed of using a wall list.

[Gamer3D]

Or better yet how about use my script that I started to convert the sprite to a model and then save it in d3d format. I do not know why you guys continue suggesting drawing multiple walls and floors with data structures when all of that stuff is unnecessary.

Noone has been suggesting drawing using data structures. Everyone has been talking about D3D models. Because D3D models are quite fast, I suggested minimizing load time.

and no Gamera3D it would not hurt to draw about 6 extra polys per pixel but when you consider he might have around 100 objects with sprites that would be a large chunk of polys and could make a real difference.

Note his example sprite. Very few pixels are actually used, so without major polygon reduction (which is possible), our methods will have similar results.

And since he has not stated that his sprites are changed dynamically at runtime then there is no need to even consider any other method because mine will be fastest to load and render and the least painful of them all.

A sprite changing dynamically at runtime will require faster load times. GML is slow. Your method uses more GML, so it would be slower at loading.

EDIT: I missed the "not". I have used [ s ] tags to indicate the part of my statement that does not apply now.

Edited by Gamer3D, 20 February 2012 - 08:45 PM.

[Gamer3D]

As a BETTER METHOD THAN SPRITES, I suggested saving lists of walls.

You suggested a ds list...

A list. An ordered set of items (Although it does not need ordering, so a set would have been a better term). I did not say ds_list because I did not mean ds_list. Also, this is for saved levels. Files. Not something to keep in memory and use to render.

Perhaps it wasn't clear that I was using the English word "list". In that case, though, the fact that I have repeatedly said to use models should indicate that I'm not telling him to ds_lists to render everything.

Hmm. I should probably leave this topic after this post. I feel like I'm dealing with someone who attended law school but never learned to read English and is now pointing out to the judge that the accused was carrying "neither a salt nor a battery." You're reading deep meaning into every word I say, but at the same time ignoring all context so that you can avoid my intent.

Read the statement you quoted me on again, because I stated since they are NOT dynamic he can convert the sprites ONCE only.

-SNIP-

And don't quote me if your not actually going to read what you are quoting me on thank you very much.

I missed 3 letters. 4 characters, including the blank. I read your statement incorrectly. I will edit my previous post to remove the erroneous interpretation.

Note that your statement is still inaccurate because your method will be slower to load.

And if he is going to use sprites larger than even 10x10 it is more efficient to write a quick conversion program.

I've been telling him to load walls instead of sprites from the beginning:

Spoiler

Alternately, consider creating your levels using walls. It'll be faster and easier than this. Also, you can create a sprite from that if you need.

I clarified:

I see I have been misunderstood. When making a level, don't make a sprite. Make a list of walls (start and end). Load that.

If you need the sprite, render a line at the base of each wall to a texture, then use that texture.

Then I clarified again:

As a BETTER METHOD THAN SPRITES, I suggested saving lists of walls. I did not suggest converting sprites to walls.

I again clarified when you assumed that list meant ds_list, despite all evidence to the contrary:

Noone has been suggesting drawing using data structures. Everyone has been talking about D3D models. Because D3D models are quite fast, I suggested minimizing load time.

The spoiler tags reduce the size of this post. They contain 4 quotes.

In short, I've suggested a better method, then tried to clarify when people read one word and assume that it has more relevance than the sentence explaining the word's context.

I say "Make a model from a list", you think "Keep a list, then draw everything from that list each step". Clearly, my attempts at communication are being lost in your interpretation. I'm done here. OP, I wish you the best of luck and skill in completing this. We mean to help you, even if we quarrel among ourselves while doing it.

[Gamebastard]

I don't know if you've solved this yet (i am far too lazy to read every post) but i wrote a program to get every pixel of an image so it can be redrawn, and i believe it can be easily converted to 3d walls instead of pixels. Take a look,

//CREATE EVENT (SCANS THE IMAGE)

for(myy=0; myy<=HEIGHT;myy+=inc)
{for(myx=0; myx<=WIDTH;myx+=inc)
{
val=draw_getpixel(myx,myy)
ds_grid_add(global.grid,myx,myy,val)
}}

//DRAW EVENT

for(myy=0; myy<=HEIGHT;myy+=inc)
{for(myx=0; myx<=WIDTH;myx+=inc)
{
val=ds_grid_get(global.grid,myx,myy);

draw_point_color(myx,myy,val);  //<---replace this with something like  'd3d_draw_wall(myx,myy,z,myy+inc,myx+inc,myz+inc)'

}}

global.grid - your ds grid
inc- the increment, number of pixels to skip by each time. 1 to get every pixel, 2 to get every other, ect. The lower the number the slower it will run but it will have more detail
myy- the y of the wall drawn
myx- the x of the wall drawn
val- the color of the wall <--important
HEIGHT - (constant) the height of the image being scanned
WIDTH- (constant) the width of the image being scanned


This was designed to scan in an image from the screen, not from a sprite, so project the image you want scanned on the screen at 0,0 and make sure the width and height match accordingly.

WARNING: This is very slow on big images, so be careful. It does work for pictures but it takes a long time and the bigger the image (amount of pixels), the slower it will run. This should work fine to draw, lets say, a pixel Mario or Pac-man

[icuurd12b42]

I'm going to go on another tangent here.

If you want to simplify making 3d walls in GM and going the way of the image and extrapolating colors was your ideas to help you...

Consider the path system in GM. There are a few people who have used the path system to easily make walls in their game. GM's path editor allows to underlay a room. you can draw your path in the path editor and using simple path functions and triangle strip model you can generate your walls quite easily. Even smooth curving walls.

[Gamer3D]

Game Maker's path system needs to be redone. It needs a minimap and zoom features like the room editor when underlay it. And it also needs to allow a point to be connected to more than just one other point.

You're talking about the editor, not the system. The system is a reasonably robust quadratic bezier spline system.

Allowing a point to connect to more than one other point permits branching. Branching adds the question "Which branch do I go on?", which is better left to the game programmer. To do this with the current system, make 2 or 3 paths. When a certain point on the first path is reached, either continue on the first path or switch to the second one. Same thing if you want to make two paths connect to eachother. If you do it right, the transition will be undetectable.

[Gamer3D]

No I could never manage a path like that and is why I had to create my own path editor to make these simple paths.

Due to the way that GM's paths work, for a curved path, you'll need to start and end the new path halfway between two points of the path. I think there are functions for doing this. To make the paths connect perfectly, place the first or last two or three points where the other path's points are. You can then check (in the object code) when you're on that part of the path, and switch

Either that or it would be nice if GM finally had vertex/index buffers because then we could make a simple non textured model to create paths like the Unity game engine.

GM's models are effectively a combination of vertex and index buffers.

I think you're thinking of arrays of points. You can do that yourself using parallel arrays. If you want a 3D (or 57D, if you wish) path, use a quadratic bezier spline. The control points will be a midpoint, a vertex, and the midpoint on the other side of that vertex.

[Gamer3D]

No I still don't like any of that at all it would be better if GM's path system just had the functionality of connecting to more than one point. As far as creating my own path system that just replicates GM's, then what is the point of even having a built in path system at all? And all of the other curve calculations and extra things that define the path should just be extra options. GM's path system needs allot of improvements.

I suggested creating your own path system because it seemed like you wanted a 3D path (when you suggested using the vertex buffers).

Here's why GM paths should not be able to branch:
A branching path prevents using a single index to store an object's position on the path (Effectively requires that multiple paths be created behind the scenes) and would require that GM supply some way to choose which path to take.
Here's why GM paths should not be able to merge:
Path speed can be -1. See above.

If you want a "better" path system, look for or make an extension for it. Paths aren't particularly difficult to implement, but implementing your own would probably help you see why GM's paths are made as they are. To get you started, you'll want to look up quadratic Bezier curves.

Let me rephrase when I said GM should utilize vertex/index buffers, it should allow us access to vertex/index buffers. Obviously every game that uses DirectX makes use of index/vertex buffers. And I like this better for making a path a model because then we don't need any messy GML code to load the path, we just call d3d_model_load() and use the theoretical vertex/index buffer functions and buda bing buda boom we have our path.

That violates a very important rule: Gameplay components should never depend on graphics components.

More importantly, exposing the inner workings of a system makes it more difficult to change the system without breaking the software that uses it. GM isn't a one-shot piece of software, so making it more difficult to change is a horrible idea.

If you want to load paths using GM's model format, you can write your own script. GM's model format is simple. Try creating a few simple models (using the linestrip primitive, because that makes sense), and looking inside; the way the format works will be painfully obvious. You can then write your own script to read through a model and load the paths contained in it. It'll probably look something like this:

read a line or two (get past version number)
while (!eof) {
  str = readline
  switch (number at beginning of line) {
    case primitive begin: start new path.
    case primitive end: stop editing path
    case vertex (of any type): path_add_point(current path, second number on line, third number on line, 100)
  }
}

So, in essence, YoYo shouldn't expose the innards of GM to you just because you can't be bothered to write... probably around 12-24 lines of code.

[Gamer3D]

Well with the paths I am not going to argue because Game Makers path system and editor are completely useless, and we should have more control over them. I don't like them because they are oversimplified so that new users can get objects to follow paths without much coding. But there is a way that it could be merged with a more advanced system and remain simplified at the same time, but I am not going to bother arguing with you over the details of it because it is pointless so just drop that subject.

No, no. The ball is in your court now. Tell us EXACTLY how to merge it with a system that does what you want while keeping it simplified. Do it in a PM if you wish. I want to hear this.

Note: The reason I want to hear this is because I have 2 example paths:

Spoiler

These paths show a couple of tricky situations. First, the relatively easy one:
If paths can join, what direction do you go on a path like the one shown?
Now the hard one:
If paths can split, which branch do you choose, and how do you give this choice to the user? (Keep in mind that adding a new branch or removing an unused one should not require changing code)

And while we're at it, let's talk about how to keep your changes from ruining some of the creative uses of the current path system:
How would you define path_get_point_x, path_get_point_y, and path_get_length?
How would you define path_get_x and path_get_y?

These simple functions would need some way to select which branch they are on (and this branch would need to be looked up based on position). It also suffers when a path rejoins itself, as in my example, because the index either suffers from a discontinuity (At which point you might as well just use GM's current path system) or the same point is described by two different indices (So the path is a simple path, and can be represented using GM's path system).

All I am saying is I disagree with you and feel it should be greatly improved, either way though I am sure you agree with me that they should add zoom features and the minimap from the room editor, I hope...

Sure. Add zoom and minimap features to the path editor. Those won't break anything, so I couldn't care less.

And I completely disagree with that YYG should expose the index/vertex buffers. This would provide us with efficient methods of animation, and so many other improvements. How nice would it be if you could edit the heights of a 3D terrain in real time without reconstructing the model? Many people are suggesting this for Game Maker 9 and it should have been available long ago, the BlitzBasic engines and DarkBasic engines had functionality for this long ago.

Animation would be a nice use of such a hack, but with the current GM model interface, exposing vertex buffers would not be the way to do it (again, because it makes it more difficult to change in the future).

If you want animation, it would be better to have the model system overhauled.

And I still disagree, I have written my own path system for Most Wanted already that allows me to make multiple connections. But as you already argued too much GML is sluggish, but you say YYG shouldn't do anything that greatly improve my games efficiency? Quite a contradicting statement there.

A GM smooth path is a quadratic function in 2 dimensions and is used once per object. Having it built-in or in GML will not make any significant difference to performance because the function itself is so tiny and little-used. In fact, a GML function this tiny could probably run as fast as a call to a built-in GM function, or faster.

Edit : And as far as the paths go I would rather have creativity and functionality over simplification or in other words bread and butter. And either way none of this matters because most of Game Makers inner workings are being completely restructured with GM9 so that more functionality can be exposed (read Mike Daily's blog) so your argument is completely mute.

• His blog hasn't been updated in quite a while.
• While it has been indicated that some of GM's innards are being reworked, the arguments against exposing them stand because GM will probably continue to have updates.

Also keep in mind that with the way GM is structured, making a system like that more complex could easily decrease the efficiency of a program that doesn't use it at all. Try adding empty objects to a room. With absolutely nothing in them at all, 10000 GM objects slow my computer to 250 FPS. When I use my custom collision DLL, adding 10000 icosahedrons to the collision environment drops my FPS to 1400.

To put things simply, I'd rather not suffer an FPS drop because you couldn't be bothered to write some code. (Or, because you claim to have written it already, reuse some code)

P.S. No, I don't like hspeed, vspeed, direction, speed, gravity, gravity_direction, etc.

[Rexhunter99]

Seeing as you all went off topic, for animation in GM what we need is two things, one is some new functions: draw_model_morphed() that takes two models, a scalar factor and interpolates the vertices based on the scalar factor, and a rigging system where vertices can be attached to 'bones' and then the bones be articulated to morph the model once more.

The model format could add one new number to it, the index of the bone the vertex or primitive is attached to, then you only need to call:
draw_model_rigged( mod, anim, ... ) with some extra arguments that define where in the animation, the model is at.

Also, being able to control whether a primitive within a model is drawn would be really useful.

[Gamer3D]

If everyone is going to utilize paths differently, then it should be some sort of system that caters to all path systems or none at all.

No system (that I can think of) could cater to all path systems. Keep in mind, however, that the path system is used by many other functions, including the mp_grid system. It's become too pervasive to be easily removed (or changed, for that matter). I'd rather avoid having more systems become pervasive.

As far as the index/vertex buffer exposure, you still did not say tell me anything bad about being able to manipulate the model data in real time, other than animation.

Animation was the good thing. It was a good point on your part.

Despite how nice it would be to have model animation, I don't think this is the way to do it. Here are some specifics of my logic behind this:

• For the sake of storage (and possibly speed), predefined primitives are probably stored using their basic information (an ellipsoid might be stored by width, height, depth, and location, for example)
• The primary problem with drawing primitives is the speed of GM function calls. This problem would still be there if animating models, although animating parts of the model would be faster.

Also as far as it being a hack, I suppose you were against the original surface fix hack to?

I didn't use the surface fix hack, but I was quite happy when surfaces were fully fixed.

Anyway, you can see some of the effects of depending on "hack" methods by looking at the DLLs that used GMAPI. Nothing that used it worked with GM8.1.

And in response to your last paragraph, I am not really sure what you are referring to there. If you mean you would not like a more advanced path system, because I am to lazy to write a few extra lines of code (which I am not, and already have), then why are you not also complaining with me about the useless one already included? And I thought you said...

In fact, a GML function this tiny could probably run as fast as a call to a built-in GM function, or faster.

So you sound really contradicting in that paragraph, please elaborate.

How do I sound like I'm contradicting myself? I have said time and again that the built-in path system is sufficient for its intended purpose, and that making it more complex would be a bad idea. I haven't defended YoYo's choice to include a path system in GM, so nothing has been contradictory.

P.S. No, I don't like hspeed, vspeed, direction, speed, gravity, gravity_direction, etc.

%100 Agree

Finally. Something we agree on.