Geometric primitives?

I was wondering if it would be possible to introduce primitives - simple geometric objects such as circle, triangle, square etc. through DX9?

Basically a feature that would draw the shape as per the supplied instructions (equation, vectors), which would also be compared in the game for collision purposes. So instead of checking for pixels, you check the actual equation that is used to draw the geometric structure. These primitives would also be scaleable - since you're drawing per vector instructions, it would always remain sharp.

I have little to no clue about programming, DX9 and stuff, so I am wondering if this would be possible. See, all graphics currently are redrawn each frame by reading the supplied texture pixel-by-pixel. What if instead it would draw directly, following supplied instructions? Isn't that what shader effects currently do - alter the texture per instructions?

Be nice to be able to draw simple geometric shapes and benefit from perfect collision checking!

This could be added, but I don't see much advantage over using sprites with geometric textures. You still get pixel-perfect collisions, you can pre-render antialiasing on the texture rather than relying on expensive multisampling for improving quality, and for some shapes like circles, textures are actually the only way to do it. Genuinely the best way to render a circle in DirectX is to draw a texture with a circle on it. The other option (a ring of vertices) would be slower, and worse quality (aliased)!

This could be added, but I don't see much advantage over using sprites with geometric textures. You still get pixel-perfect collisions, you can pre-render antialiasing on the texture rather than relying on expensive multisampling for improving quality, and for some shapes like circles, textures are actually the only way to do it. Genuinely the best way to render a circle in DirectX is to draw a texture with a circle on it. The other option (a ring of vertices) would be slower, and worse quality (aliased)!

Why do everyone cares so much about "the best way"?! There is not a best way to do a thing! I could have advatages even if I draw a polygonal circle instead of a texture! Is that kind of feature so hard to do? If you want to create a FULL 2D game creation app don't you think that you NEED to let the developer to decide if he wants to use a texture or a polygon?? We have DUAL and QUAD cores!! And apart that, who cares about the lose of 1-2-3-4 FPSs??! I could have my reason to draw a polygonal shape instead of a texture!! Don't you think?

I wonder why everyone is so against this kind of feature. Polygons with textures and collision checking. Is that so difficult? So difficult for you that MADE the entire CONSTRUCT?

This is not even the first time a user asks for this kind of feature. And noone helps those users. We are not all expert coders!!

Ok, now I feel better.

Chill pill, Genesys?

Anyway, Ashley: It is not a matter of efficiency; there are times when I wished I could simply draw a geometric shape (or polygon) instead of having to use a pre-rendered texture. Having the feature I described would be quite a boon for game developers.

Here are the advantages I can think of:

• you can update the shape in real time, while a static texture remains the same. Imagine real time graphs! And that is not the only thing you could do in the game.
• collision checking is easy between geometric primitives, because you can simply solve rather than check for each pixel, where even slightly transparent pixel can throw the alarm bells off.
• I mentioned transparent pixels... well, static textures, when zoomed in, have these all over the place. There would be no such "dirt" with polygons.
• low memory footprint. A huge circle (to preserve crispiness) can easily take a good chunk off memory, while a primitive circle would take substantially less (if we draw directly to the visible screen, skipping offscreen). Static texture still retains the same space, even if it is not drawn offscreen.

Efficiency is not a concern, when it comes to numerous possibilities we can create with these objects.

Why do everyone cares so much about "the best way"?! There is not a best way to do a thing!

Perhaps, but some ways are clearly better than others. And isn't your entire rant about doing something a better way?

I wonder why everyone is so against this kind of feature. Polygons with textures and collision checking. Is that so difficult? So difficult for you that MADE the entire CONSTRUCT?

The devs don't even have much time to work on bugfixes, which are of much, much higher priority. Maybe they could consider it for C2, but there's more important stuff to be done on C1.

This is not even the first time a user asks for this kind of feature. And noone helps those users. We are not all expert coders!!

They can't implement everything people want immediately. Construct is a free piece of software written in the dev's spare time. I think we all can agree that there are more important things to work on first, like bugfixes, and perhaps even online capabilities (not sure what the status is on that. Seems to be a lot of different info), etc.

I'm not against the feature - I just think that most of what could be achieved with it can already be done, and other stuff is more important.

I know Construct is free. But I feel like the devs never hear what we ask! I feel alone!

I Totally Quote Mipey.

And I also know that devs doesn't have much time to work, so they work on bugfixes for now. But I feel alone anyway

I think the collision thing you speak of would require a lot of work. Probably the fastest way to check the collisions would be to render the vector graphic onto a texture then pixel check that. Otherwise I guess they would have to write some sort of equation solving collision engine (unless dx already has some sort of library built in for this, which I'm guessing is more than plausible.).

Anyways, I'm all for some sort of geometric drawing capability, but I believe it's too much work right now to expect anything useable in the near future. What I would really like to see is polygonal drawing capabilities with the canvas. Speaking of canvas, there's a hell of a lot of bugs with it... Guess I better go report them.

For the record, it is not like I am demanding this feature, I was just wondering if it was feasible. Of course I can live without it, but hey, if this was possible, it would certainly expand game developer's options!

What about shaders? Would it be possible to draw primitives based on given parameters? Grab an empty sprite, assign the effect to it and set some parameters. Not the most elegant way, but hey... imagine drawing with shaders. Hella slow, I bet.

I would use canvas, but it is restrictive in many ways.

IndieLib does this, and it's really nice. =D

I ain't no programmer and IndieLib is a C++ library.

Ill just leave this here:

http://dl.dropbox.com/u/666516/polycollision.cap

Wow, unexpected surge of opinion! The thing is, it's not quite so simple as you might think, especially when it comes to circles.

- you can update the shape in real time, while a static texture remains the same.

Isn't this what mesh distortion does?

[quote:3fa4nrb2]- collision checking is easy between geometric primitives, because you can simply solve rather than check for each pixel

Actually, the opposite is true. Most of Construct's collision engine uses per-pixel collisions, and that makes detecting collisions between geometric primitives and per-pixel sprites extremely difficult. I don't really want to add new features unless they integrate with all other features, especially something as intuitive as collision checking (where if any combination simply didn't work the forums would be full of people asking "why doesn't my 'on collision' event work here?")

[quote:3fa4nrb2]- I mentioned transparent pixels... well, static textures, when zoomed in, have these all over the place. There would be no such "dirt" with polygons.

I don't see the point here. I think it is quite simple to ensure you have a clean polygon sprite on a texture.

[quote:3fa4nrb2]- low memory footprint. A huge circle (to preserve crispiness) can easily take a good chunk off memory, while a primitive circle would take substantially less (if we draw directly to the visible screen, skipping offscreen). Static texture still retains the same space, even if it is not drawn offscreen.

You might save one texture, yes. But the rendering of a circle is much slower. The way it'd have to be done in Construct is basically create a circle out of straight lines, which means hundreds of vertices arranged in a ring. (As I said before, DirectX can't natively draw circles, only triangles) And four vertices is equivalent to pushing a sprite to the graphics card, so you could end up with a single circle using the rendering power of a hundred sprites.

You could use a shader, but why require special pixel shader hardware for something as simple as a geometric primitive?

Given all this, I'm afraid I don't see much case for a series of geometric primitive plugins. A third-party dev could try making some, but it would still suffer the same pitfalls - probably no collisions with ordinary sprites and slow rendering of circles. Really - is there something that bad about using sprites with textures?

Thank you for your answers, Ashley. I was merely exploring my options and I appreciate your input on this topic.

Perhaps, a plug, or third party program, like the mesh editor? One that was made to speed up making polygons. Then you could just import the mesh's, then for collision detection you could just use a canvas like my example above.

and unfortunately Ashley has to waste his time explaining why their isn't a specific feature in construct, rather than touching up on the project itself

Damn demanding public.