• entries
743
1924
• views
578747

# Arbitrarily Complex Fish

148 views

Written a vector based editor for creating the environment for my game:

Here are a collection of spheres bouncing off and interacting physically accurately with an arbitrarily complex fish.

I'd like to think that that sentence has never been posted before.

It will all look a lot better when textures are dropped in. I've got texturing working in the editor and it looks a lot better.

The overall idea though is that you construct the environment out of as few physics polygons as possible, but since the quads are forced to multiples of the texture base size (64x64), they are just textured with wrap mode and look like a grid of smaller quads.

This reduces the number of polygon intersection tests.

The editor generates the polygon vertex info and will soon generate the texture co-ordinates as well. I'm planning to atlas the map textures so the map can hopefully be drawn with one DrawPrimitive call.

Oh, further to my revamped graphics wrapper, I've got atlased fonts working. I was suprised to find I can fit Tahoma, size 8, bold A-Z, 0-9, a-z and some punctuation onto a 128x128 texture.

I did try to write a new font file generator with C#, but it seems that GDI+ returns some very weird numbers from MeasureString(). According to various bods on the internet, this is all to do with how clever it is at rendering text in a device-independant manner or something. Just a bit of a bastard as far as I'm concerned.

My current, working font file generator was written ages ago with Borland Builder and since I don't have Builder installed anymore (it won't coexist nicely with Borland's command line compiler, which I still use) I can't alter it.

Might have to rewrite it in straight Win32 to avoid this GDI+ problem.

That is indeed, a very arbitrarily complex fish. Looks cool though.

Looking good, EC. I'm looking forward to the point where we can swap editors and compare our work. Mine runs pretty much on homebrewn GUI, since there's no Win32/WinForms API around my code, so I'm guessing you'll win on the user-friendliness front. (Since we both seem to be writing polygonal map editors. [grin])

Best of luck!

Quote:
 Original post by HopeDagger Looking good, EC. I'm looking forward to the point where we can swap editors and compare our work. Mine runs pretty much on homebrewn GUI, since there's no Win32/WinForms API around my code, so I'm guessing you'll win on the user-friendliness front. (Since we both seem to be writing polygonal map editors. [grin]) Best of luck!

That's really weird. Just had a look at your screenshots. I caught your comment in Sir Sapo's journal the other day. I genuinely started this project before I read that he had started on this polygon intersection stuff, and have literally just looked at your screenshots and heard Twilight Zone music in my brain.

You seem to have cracked texturing more complex shapes than me though. My physics code can cope with collisions with any convex polygons, but working out how to texture them is eluding me at the moment.

Regarding the fonts, it doesn't use Win32 to render them. A seperate program uses Win32 to generate a file containing a list of square textures representing each letter, along with an unsigned char Index[256]; array that gives the index in the list of each letter.

The images are then atalased onto a Direct3D texture when the font is loaded, and the TextureFont class works out the tex co-ords for two little triangles when rendering each letter into a vertex buffer.

So in theory, you could use my font files with pretty much any 2D or 3D graphics API. I thought that having the one file was a bit tidier than that Bitmap Font Generator program that everyone seems to be using. It's just an extension of my .spr format for storing multiple images with alpha information in a single file.

Nothing against your wonderful fonts, but I wrote 'front', not 'font'. [grin]

Regarding the texturing:

It's far easier than you think, good friend. The texture coordinates simply equivalent (or with some arbitrary scaling) to the world coordinates of the vertex. Since texture coordinates repeat (or rather, they can repeat if the right texture states are set), the texture will simply tile seamlessly over the polygon. Since your world rotates around you, remember to use the non-transformed world coordinates instead of the screen coordinates.

Quote:
 Original post by HopeDagger Nothing against your wonderful fonts, but I wrote 'front', not 'font'. [grin]

Doh! [smile]

Quote:
 Original post by HopeDagger Regarding the texturing: It's far easier than you think, good friend. The texture coordinates simply equivalent (or with some arbitrary scaling) to the world coordinates of the vertex. Since texture coordinates repeat (or rather, they can repeat if the right texture states are set), the texture will simply tile seamlessly over the polygon. Since your world rotates around you, remember to use the non-transformed world coordinates instead of the screen coordinates.

Guess that makes sense. I'll have to have a play around with it.

I was actually quite inspired by your level editor screenshots so I'm rewriting mine.

Quote:
 Original post by EasilyConfused I was actually quite inspired by your level editor screenshots so I'm rewriting mine.

I can send you a copy of what I have so far if you think you would be able to sheer off some/any ideas for your own. Heck, you're welcome to build off of what I have so far, if you're so inclined.

Just tried your suggestion with the texture co-ords=world.co-ords and of course it works.

I'm dividing the world co-ord by the texture width, and all systems go.

I guess though that I can't atlas textures that I want to wrap.

Appreciate the offer of your code, but I reckon it would just confuse me. I never seem to be able to make sense of all but the most trivial of other people's code.

Believe me, your suggestion above has solved the vast majority of the problems I was having.

Quote:
 Original post by EasilyConfused Just tried your suggestion with the texture co-ords=world.co-ords and of course it works. I'm dividing the world co-ord by the texture width, and all systems go. I guess though that I can't atlas textures that I want to wrap.

Not at all. The auto-wrapping is a nice feature to take advantage of, but it's not like it's the *only* way to repeat your texture over the 0..1 range. Right now, your UV coordinates are generated something like this:

float u = vertex->x / polygon->texture->width;
float v = vertex->y / polygon->texture->height;



Which will give you the right values over an infinite plane filled with the wanted texture repeated. However, you can simply divide out the whole-number portion of each coordinate to keep the number between 0 and 1:

float u = vertex->x / polygon->texture->width;
float v = vertex->y / polygon->texture->height;

u /= int(u);
v /= int(v);

/* Note: If maintaining the sign is important (above gives you positive always), then "u /= abs(int(u));" preserves it. */



I do recommend precalculating these though, since divisions and integer castings will eventually catch up with you on bigger maps.

Quote:
 Appreciate the offer of your code, but I reckon it would just confuse me. I never seem to be able to make sense of all but the most trivial of other people's code.

It's always difficult to try and make sense of someone else's code -- it's not just you. Everyone has their own unique style and methods to doing things, so it's tricky to make sense of it. However, it is an excellent skill to learn (at least if you plan on getting a job writing code), as it can oftentimes prevent you from reinventing the wheel for the 100th time, and even learn new tricks.

Gripes aside, hopefully that helps. Continued good luck on your development.

Cheers. I was wondering about making maps bigger and bigger and buggering up the texture co-ords. Looks like the above will solve it.

## Create an account

Register a new account