GDR Forum Index
Podcast Podcast
Dev Dev Logs
Search Search
RSS RSS
Register Register
Log in Log in
Reply to topic GDR Forum Index -> Game Developer's Refuge -> Development Log - GEL and Foundation (Engine Tools) Page Previous  1, 2, 3, 4  Next
View previous topic :: View next topic  
Author Message
PoV
Moderator

Joined: 21 Aug 2005
Posts: 10902
Location: Canadia
PostPosted: Sat Jun 05, 2010 9:02 am    Post subject: Reply with quote

June 5th - 1:02 AM
Decided I wanted to play with scripting languages today.

I've been eye'ing Lua for the past several years as my potential scripting language to use. I even bought the books (Lua's 2, Lua Gems, ...). But I've never been a fan of some of the things Lua does stock. The whole counting from 1 instead of 0, begin and end instead of { }, doubles as the default number type, among other things. I realize there are hacks/extensions you can install to get around these, but then it's no longer a stock Lua.

We had a brief chat in #ludumdare about the possibility of creating a CLua language, since our complaints about Lua are pretty much the same. "It's not C-like enough".

I decided to do an assessment of scripting languages recently, and discovered one called Squirrel. It uses a more C/C++ like syntax, though not as heavy. That was something I really didn't like about AngelScript: it's practically a full reimplementation of C++. I don't need that!

Performance wise, Squirrel is said to be slower than Lua, but to be honest I'm not really bothered by that. The bottom line here is I'm adding a scripting language for me, not artists or modders to use, and I'd like to syntactically do something comfortable for me.


The first step here will be to add some way for me to start making "test programs" or "prototypes" to my source tree. Right now the "src/Game" folder contains my actual game code, so I'll be adding another top-level source folder for experiments like this. I'm going to mull over this for a bit.
_________________
Mike Kasprzak
'eh whatever. I used to make AAA and Indie games | Ludum Dare | Blog | Tweetar
View user's profile Send private message
PoV
Moderator

Joined: 21 Aug 2005
Posts: 10902
Location: Canadia
PostPosted: Sat Jun 05, 2010 12:44 pm    Post subject: Reply with quote

June 5th - 4:44 PM
Heh, I'm slowly dragging along today. It's like I have a headache, but I don't. Anyways...

I ended up adding a /src/Experiments folder, and two more folders under that (SquirrelScritping and Stub, the later is a template). Then I added Squirrel to the source tree as well (Version 3 beta), and spent some time reading the docs.

Getting the Experimental stubs working required creating a new set of stubs for Audio. Audio playback in Smiles is a bit messy. There's a list of file and enum names hardcoded in a couple files, and the init function bulk loads all these files. So I've added a placeholder that doesn't do this anymore.

Eventually I'll have to add a bunch more handle types. Right now I have something called the TexturePool, which returns an Id (Handle) for any texture file you want loaded. If the same file is requested more than once, the same Id (handle) is returned. I'm going to need to extend that for other content sources soon. Meshes (which will contain texture and material handles), materials (shaders), perhaps scripts too (or maybe just generic content), and soon sound effects and music.

But back to the original point, the scripting stuff is ready to test... but as said at the top I'm moving a little slow today. I'll probably take a break now, until I come up with something I want to do next.

I haven't really figured out where I'll be using scripting in a game, but probably as means for event/scenario building. I'm not a fan of the "make a game in a scripting language" angle. I'd prefer to build an engine proper, but let scripting control the engine in some way, allowing you to extend the behavior of things beyond linear canned actions.

Either way, there's much more to do before we get that far, but the mini goal of adding a scripting language to the source tree is done.
_________________
Mike Kasprzak
'eh whatever. I used to make AAA and Indie games | Ludum Dare | Blog | Tweetar
View user's profile Send private message
sonrisu
Moderator

Joined: 31 Aug 2005
Posts: 4998
Location: Silicon Valley!
PostPosted: Sun Jun 06, 2010 12:40 pm    Post subject: Reply with quote

Quote:
Eventually I'll have to add a bunch more handle types. Right now I have something called the TexturePool, which returns an Id (Handle) for any texture file you want loaded. If the same file is requested more than once, the same Id (handle) is returned. I'm going to need to extend that for other content sources soon. Meshes (which will contain texture and material handles), materials (shaders), perhaps scripts too (or maybe just generic content), and soon sound effects and music.

This is so incredibly useful. I have this setup and it has made my life a million times easier. Note that this exists solely for my game though, and isn't a part of my engine. It should be, some day, though. I extended what you've described a further such that I can ask for any resource by name and it is simply found and returned (loaded if it's not already resident in memory). I call it a resource manager but at the end of the day all it really is is a cache of recently loaded items with a bit of a frontend to handle the gruntwork of finding files for you.

Looks something like this:
Code:
ResourceManager *resourceManager;
resourceManager = resourceManager->instance(); // It's a singleton
SMTexture *someTexture = resourceManager->texture("myTexture");
SMSample *someSound = resourceManager->sample("someSound.wav");
SMMusic *someMusic = resourceManager->xm("someXMFile.xm");


The next time you ask "resourceManager->xm("someXMFile.xm");" you'll basically get a pointer to the same object as "someMusic". You can clear out the caches wholesale only at this point. Some day I plan to make it smart and start removing things you haven't accessed in a while. For now, I let it bloat up. ;) I highly suggest you build in the ability to find things by name. It's a million times better than having to know the paths to things (especially if you're hard coding in the paths). Then you can rearrange how your assets are on disk however you want. You pay a bit of a penalty by having to do a search the first time the asset is loaded (or any load after it has been unloaded), but in my opinion it's well worth it.

I'm unsure how crazy that would be with the multiplatform issue regarding filesystem.. Across Win/Nix/OSX it's not that bad for file search.
_________________
loomsoft :]
View user's profile Send private message Visit poster's website
PoV
Moderator

Joined: 21 Aug 2005
Posts: 10902
Location: Canadia
PostPosted: Sun Jun 06, 2010 2:26 pm    Post subject: Reply with quote

Yeah, I already do named searches "/MyTexture" (no extension to allow for any textured with that base-name, the first pattern match wins (hence the slash)), and I also don't currently automatically free resources. ;). I can kill them all, or just certain ones, but it's all manual right now.

I record frame-stamps on everything (last time it was requested by name, but only then), but don't do anything with it yet.

Introducing dependent objects like 3D models kinda makes things a little more complicated. :)
_________________
Mike Kasprzak
'eh whatever. I used to make AAA and Indie games | Ludum Dare | Blog | Tweetar
View user's profile Send private message
PoV
Moderator

Joined: 21 Aug 2005
Posts: 10902
Location: Canadia
PostPosted: Sat Jun 12, 2010 1:16 pm    Post subject: Reply with quote

June 12th - 5:16 PM
Not much coding the past week. I've been mostly caught up planning, researching, and thinking a-lot about what I want to do for my next game. Anyways, the vision is further along now, so it's time to get back to this stuff... the "how I'm going to make it happen" side.

I started off the day putting some thought in to the various systems and things I'll want running and existing in the game world. Multiple room sized terrain renderers, distortable water planes, constrained particle systems (capable of physical interaction), among other things. Ultimately, I'm going to need something like a scene graph. This got me thinking about some other things that should change structurally.

- - -

I have 2 core libraries now. GEL (Game Engine Library) and Foundation. GEL is all the low level platform specific, math, and file/data format code, where Foundation is higher level stuff built on top of it (UI, tools, renderers, etc).

Right now, Foundation is just a bunch of stubs, and only the graphics code from GEL feature any notable prefixes (gelDrawPolygon). The contents of GEL feature a few different coding styles, with good reason, but the rules are a little vague. So now that I have a further agenda for Foundation, I think it's a good time to introduce some explicit style rules, as new code will likely conform to one of the style systems.

First off, every library needs an abbreviation. GEL is obviously "GEL", and Foundation will be "FD". Case will be adjusted depending where it's used.

Global functions (in general) will appear as lower case prefixes of all functions. libraryFunctionName(...). i.e. gelDrawPolygon(...), fdDrawMouseCursor(...).

Global defined constants and bits will use the OpenGL like scheme. LIBRARY_TYPENAME_OPTIONALMODIFIER, LIBRARY_LONG_SPOKEN_STATEMENT. i.e. GEL_LEFT, FD_CENTER, GEL_AUTODETECT, GEL_DATABLOCK_CONSTANT.

Then comes types.

Types come in 2 flavors. Ordinary C++ Classes, and Raw Types (for lack of a better name). Both support construction/destruction and numerous methods, but are implemented slightly differently.

Ordinary C++ classes are implemented as expected. The constructor constructs the object, and the destructor destroys it. They are self sufficient, and are incapable of malformed uses. cLibraryClassName { }. i.e. cGelFile, cFdGraph.

Raw Types break a number of prior rules. They are whole types, assumed to be (for the most part) linear blocks of data with a header. Some Raw Types don't follow this rule (i.e. contain other Raw Type *'s as members), and simply rely on the raw type syntax.

Raw Types are always pointers to the type. An instance of a DataBlock will always be a DataBlock*. A DataBlock (for example) is a size followed by that many bytes of data. Ideal for bulk loading or saving to a file.

Raw Types are explicitly constructed and destroyed. The type itself contains no methods. Instead, global functions with the syntax action_TypeName are invoked. i.e. DataBlock* MyData = new_DataBlock( 256 ); delete_DataBlock( MyData ); Specializations are defined as action_specialization_TypeName. i.e. GelFile* MyFile = new_readonly_GelFile( "Gravy.bin" ); Raw Types use standard C functions, so creating specializations DON'T require any changes to a class. You can simply overload existing functions, or come up with a noteworthy action name for your new call, and include your specialization header file anywhere it's needed. And since a Raw Type is explicitly created and destroyed, it's more open to weird "pointer munging" and other advanced memory conscious manipulations.

Raw Types I'll be naming LibraryTypeName from now on. i.e. GelFile, GelDirectory. This contrasts classes that feature a lower case "c". Right now all Raw Types are named DataBlock, Array, Directory, etc. Kinda tricky to know what's part of the library and what isn't.

However, I will be breaking the prefix rule with a few things I consider "should be built-in types". Very few of these. Currently that's only DataBlock, Data (which is an implicit name for char*'s), Real (synonym for float), VectorXD (X being 2,3 or 4, vector math types), and MatrixXxY (2,3 or 4). Like the Rebel name removed recently this may change, but the above are all things that really should be built in to the language. Vector and Matrix math is available via SIMD instructions, and an allocated chunk of memory *really* should have a way of knowing it's size (DataBlock).

That's the gist of the naming style.

From the work I've done so far though, I do have 1 last thing that could use improvements. General library specializations. For example, I have the occasional piece of platform specific code, or a support function for implementing several calls in an implementation. These functions are named things like gelSupportInitAccelerometer ("gelSupport"), and often make a #define like GEL_SUPPORT_INITACCELEROMETER once used. Calling of that function is wrapped in an #ifndef, so an Accelerometer test will never need to be done on a system without one. Specializations show up sometimes as dummy functions. gelVertexPointer, as a synonym for the OpenGL glVertexPointer call. Behind the scenes it's calling glAttribPointer, since the syntax is different than glVertexPointer (the point of this is to easily make non-shader code work in shader-based GL). gelVertexPointer is a lie though, since it's not actually a proper GEL member.

So for specializations I'm going to include an extra character, similar to the relationship between GL and GLU. In the above case it'll be "s" for support, gelsVertexPoint, gelsInitAccelerometer. These functions should never be called outside of GEL itself, the only exception being a Main function or other platform specific code. It should act like an easy to see cue for what's platform specific and what isn't. That, and gelSupport is REALLY LONG! HEH!

Elsewhere, back on my topic of a scene graph, I'll probably end up creating a base object type in Foundation: cFdObject. I think it would be wise to mark objects meant for a scene graph (or similar entity) as such. cFdoTileMap, cFdoHeightMap, cFdoWavePlane, etc.

- - -

On promoting features to Foundation, I have a texture pool inside GEL right now. Once the content pool goes general purpose, it should live in Foundation. I wasn't sure what to do about a mesh loader that references textures by name. I had planned to, in a single call, load the mesh and any textures needed, but I think I wont do that (at least at the GEL level). The GEL cal will be for loading the mesh file format. Other code (likely on the Foundation level) will have to iterate all required textures by the mesh.

- - -

Anyways, that's where my code thoughts are right now. I might dive in to the restructure after some dinner. Generic Pools I'll attack another day.
_________________
Mike Kasprzak
'eh whatever. I used to make AAA and Indie games | Ludum Dare | Blog | Tweetar
View user's profile Send private message
PoV
Moderator

Joined: 21 Aug 2005
Posts: 10902
Location: Canadia
PostPosted: Sat Jun 12, 2010 8:29 pm    Post subject: Reply with quote

June 13th - 12:30 AM
Heh, just missed the before-midnight mark.

Finally got around to doing some of the cleaning mentioned a page ago. "Stream" is now gutted from all the "/Core" types. Others like Deque and StaticArray have been removed.

Renamed several types as suggested in the last post. Array is now GelArray, Heap is now GelHeap, Archive is now GelArchive, and DIRECTORY is now GelDirectory. The directory reads much better now, with Data, DataBlock and DataArray on top. File and VFile still need to be renamed to their Gel equivalents, and still need the content and storage loaders mentioned some posts ago, so they're more work (...actually, VFile could be done now). :)

I renamed a class "Grid2D" to cGelGrid2D, as that conforms to the new style rules. cGelGrid2D is a type for holding 2 dimensional data. The class version has a ridiculous number of features, from blitting to alpha blending, to match detection, falling rules (Normal/Smiles style, Rockford/Boulderdash Style), and many many more things. It's an 80kb source file itself. :)

Anyways, the point is I'll be needing GelGrid2D again for *much* stuff. I'd like to add a tilemap+texture atlas renderer to Foundation (cFdTileMap), as well as a height-map renderer (cFdHeightMap), among other things. The point, it's a class for any 2D data usage.

I've started creating a non class adaptation GelGrid2D. So far it has the new_GelGrid2D and delete_GelGrid2D functions, but that's it. I'll be coming back to this for sure, since 2D data is so essential. The point of creating the GelGrid2D variant is so I can use it the same way as I use DataBlock (i.e. everywhere!). For example, in a simple chunked file format with a size followed by data, I just cast a pointer to the whole thing to a DataBlock. I'd like that, plus all the image editing and manipulation features available to me for any raw-loaded files, without the need to convert them.

I put a stub in for a new type, GelData2D. Like the Data series of functions, but for 2 dimensionally arranged data. Standalone functions and operations, without any needs for non built-in types.

Hmm... actually I'm starting to think maybe I should invoke my rule of "should be part of the language" features with Grid2D and Data2D. DataBlock and VectorXD are types that I could/may use to directly interpret the contents of memory, which can also be said for Grid2D (i.e. this is image data). File's and Directories conflict with system/OS named things sometimes, so they get Gel'ed, but a Grid2D is a pretty safe name (like Vector2D, Vector3D, Vector4D).

I need a variation of the Grid2D. Grid2D will work with any type 8bits and larger (char, short, int, float, custom type), but some image data will be stored in 1bit, 2bit, and 4bit encodings. It might be nice to have some operations available here. BitGrid2D?

I guess that's all for now. I think I'll go fix GelGrid2D back to Grid2D, add a stub for BitGrid2D, and make VFile in to GelVFile (since I can, in anticipation of File becoming GelFile).

Fun fun!

EDIT: Okay, added a creatable and destroyable BitGrid2D (i.e. non class version, Raw Type). Bits Per Pixel are a template argument, so they can be used anywhere a Grid2D can.

EDIT [1:30 PM]: And now VFile is GelVFile. I'll dig around the GEL folder some more, to see if there's anything else I'm in the mood to rename.
_________________
Mike Kasprzak
'eh whatever. I used to make AAA and Indie games | Ludum Dare | Blog | Tweetar
View user's profile Send private message
PoV
Moderator

Joined: 21 Aug 2005
Posts: 10902
Location: Canadia
PostPosted: Sat Jun 12, 2010 11:22 pm    Post subject: Reply with quote

June 13th - 3:22 AM
Started adding the new file code. I created a macros for generating the functions. It compiles.

The next step was to add path generation. Given a filename, append the appropriate prefix depending on the platform and content request type (content, storage, temp storage), the load/save it. This was all happening inside "/Core", until I noticed that "/Core" was all headers. Types and inline functions. Hmm.

What this path thing *should* be is a single call init function, determines the path(s), then all subsiquent content and storage requests are ready to go.

Also, maybe this specialization of content and storage paths shouldn't go under Core?

So, for lack of a better name, I created a new directory under GEL: "System". The path code is there now, but needs cleaning up. I've also added dummy headers for all the Core types there. System/DataBlock.h as an example. What these currently do is include their "/Core" counterpart, and give the option to add some specializations right after. i.e. new_content_DataBlock(...). So that's what I'm going to do. Keep core clean of the actual path generation stuff, but still define the functions used to for reading/writing to content and storage sources.

Sleep time.
_________________
Mike Kasprzak
'eh whatever. I used to make AAA and Indie games | Ludum Dare | Blog | Tweetar
View user's profile Send private message
PoV
Moderator

Joined: 21 Aug 2005
Posts: 10902
Location: Canadia
PostPosted: Wed Jun 16, 2010 9:20 pm    Post subject: Reply with quote

Spent the past couple days reading, reading, and more reading. Running through my head is the that I have *maybe* 5 months to get a playable ready for the IGF. So 2 months to get a 3D engine+tools together so I can start building my content, a brief interlude to finish a Smiles port, then a 2 month crunch to make a real game.

I've been through the GPU Gems books (1-3), Graphics Programming Methods, and Game Engine Gems (1) so far. Given my timeline, what I'm looking for in many cases is the simplest way to make it look super-freaking-sweet. Least effort, most awesome.

I need a small, instance-able terrain renderer. The books covered several distance optimization techniques for terrain, but I'm going to brute force it (since I'll be viewing my terrain from a near top view all the time).

Spent a-lot of time reading about post processing effects. I'm going to want lots of glow (not bloom), and some sort of full screen blur effect (either motion blur or DOF, probably motion blur). There may be cases where I pre-bake the glow.

I found some "good enough for me" global illumination effects in the GPU Gems books. They're listed as fast+realtime, but I don't really need realtime. What's important: they are straight forward "run it a few times and a lit scene looks cooler".

Bump/parallax/relief mapping, sure. It just doesn't look shiny without them.

What I didn't yet much in to was lighting and shadowing. No real agenda here yet, but I still have 15 Game Programming Gems and Shader X books to get through to find my best+easiest solution. I've been stepping through these gems series books backwards, since they latest ones will have the most currently relevant tips in them, targeting OpenGL ES 2 "On Crack" as I am (i.e. no geometry shaders, though I do have plans to generate some data on CPU).

Oh and I've been reading up on Stereoscopic 3D too. :D

The point: I don't want to be in a situation with my design where I can't do something, due to a design flaw I made right now. So I'm absorbing tons of information right now, and cataloging what I want and need.

Because somehow, this has to happen in 2 months... heh.

PS: I'm working on this again, with a new name, same general goals... but replace "PS2 era" with PS3, since I'm just that ambitious. :)
_________________
Mike Kasprzak
'eh whatever. I used to make AAA and Indie games | Ludum Dare | Blog | Tweetar
View user's profile Send private message
n29
Developer

Joined: 13 Sep 2005
Posts: 879

PostPosted: Thu Jun 17, 2010 2:53 pm    Post subject: Reply with quote

I'm really anticipating hearing your plans for dynamic content generation. The requirement for massive amounts of content is what destroyed my motivation for independant game development. Can't wait to see how you're approaching it.
View user's profile Send private message
PoV
Moderator

Joined: 21 Aug 2005
Posts: 10902
Location: Canadia
PostPosted: Sat Jun 26, 2010 9:48 pm    Post subject: Reply with quote

June 27th - 1:48 AM
Projection and frustum culling today. Pink is orthographic, and the other 3 are different levels of perspective.



Took me a while to get my matrix math right, but it works now. The perspective function I can give a rectangle to (i.e. a screen or texture shape), and say how deep inside the frustum to place the plane that maps 1:1 to that. The default is right in the middle, but something like an FPS would want a further draw distance.

I suppose the only thing missing is some way of controlling/calculating the FOV by angle, and to built an actual camera type (a new one rather, since the old one is totally wrong).

Math fun fun.
_________________
Mike Kasprzak
'eh whatever. I used to make AAA and Indie games | Ludum Dare | Blog | Tweetar
View user's profile Send private message
PoV
Moderator

Joined: 21 Aug 2005
Posts: 10902
Location: Canadia
PostPosted: Sun Jun 27, 2010 12:26 am    Post subject: Reply with quote

June 27th - 4:26 AM
Added a Look-At function, so some playing with the perspective.



Sleep time.
_________________
Mike Kasprzak
'eh whatever. I used to make AAA and Indie games | Ludum Dare | Blog | Tweetar
View user's profile Send private message
PoV
Moderator

Joined: 21 Aug 2005
Posts: 10902
Location: Canadia
PostPosted: Sun Jun 27, 2010 1:50 pm    Post subject: Reply with quote

June 27th - 5:50 PM
Curves. So far I have a working Cubic Hermite in (end points and tangent vectors for controlling curve shape, like you get in vector art software).



Unexpectedly, it seems the tangent vectors affect the curve less than I was expecting they would. I needed really large tangent vectors just to get that light curve you see there. Ah well, I'll look in to it more once I start working on tools that use it.

On to some other curves now.
_________________
Mike Kasprzak
'eh whatever. I used to make AAA and Indie games | Ludum Dare | Blog | Tweetar
View user's profile Send private message
PoV
Moderator

Joined: 21 Aug 2005
Posts: 10902
Location: Canadia
PostPosted: Sun Jun 27, 2010 5:34 pm    Post subject: Reply with quote

June 27th - 9:34 PM
More curves. Bezier this time.



Pretty much done with these. Now to figure out the next random thing to do. :)
_________________
Mike Kasprzak
'eh whatever. I used to make AAA and Indie games | Ludum Dare | Blog | Tweetar
View user's profile Send private message
Ninkazu
Contributor

Joined: 21 Sep 2005
Posts: 482
Location: Seattle, WA
PostPosted: Sun Jun 27, 2010 6:06 pm    Post subject: Reply with quote

B-splines. Much nicer to work with than Hermite curves (which are nicer than Bezier curves).
_________________
Get woke. Stay woke. ~@deray
View user's profile Send private message Send e-mail Visit poster's website
Bean
Admin

Joined: 20 Aug 2005
Posts: 3776

PostPosted: Sun Jun 27, 2010 6:19 pm    Post subject: Reply with quote

Funky stuff! I've always wondered if I should have done more of the lower level stuff myself instead of relying heavily on DirectX. On one hand I know my game will be fast and use hardware. On the other, I'm stuck on Windows.
Pros and cons to everything I guess. Nice to see other people taking different directions though.

-Bean
_________________
Kevin Reems | Nuclear Playground | Solid Driver
View user's profile Send private message Visit poster's website
PoV
Moderator

Joined: 21 Aug 2005
Posts: 10902
Location: Canadia
PostPosted: Sun Jun 27, 2010 9:09 pm    Post subject: Reply with quote

Ninkazu wrote:
B-splines. Much nicer to work with than Hermite curves (which are nicer than Bezier curves).

I have those too, but I liked the results of the the ordinary Bezier curves better (since they actually reach endpoints). But your right. Unless there's a mistake with my math, something seemed wrong with the Hermite curves.

But wow, I love how simple the ordinary Bezier Curve math is. I'll probably end up using that as a cheap no-effort smoother when I get around to the terrain generation stuffs. That or the Catmul-Rom. I went through a whole list of algorithms, even KB Splines, but I think there might have been something wrong in the math there since it didn't do much.

June 28th - 1:09 AM
More Curves!

This time we have waveforms:


And interpolation curves:


So in addition to Sin, Cos, Tan, and ArcTan (all set up for 0-1 ranges), I added a SawTooth, Saw (up and down), and Square Wave functions, the last 2 with period controls.

I used to hardcode ease-in and ease-out curves (Pos += Distance * Scalar), but I added some functions for achieving the same effect in the 0-1 range. I also added a Lerp function and a Smoothing function (x*x*(3-2*x)) for completeness. Obviously the Lerp function does nothing useful, but something I completely forgot was with the 0-1 range is you can chain together the interpolated results for different curves! The interpolation curve in the image above is an Ease-In curve combined with a Smoothing curve (making the tail a little less rough). Shwheet!

Oh, and I added inverted versions of everything too (backward SawTooth).

Now what...? I dunno... heh.
_________________
Mike Kasprzak
'eh whatever. I used to make AAA and Indie games | Ludum Dare | Blog | Tweetar
View user's profile Send private message
PoV
Moderator

Joined: 21 Aug 2005
Posts: 10902
Location: Canadia
PostPosted: Mon Jun 28, 2010 11:32 am    Post subject: Reply with quote

IGF deadline was just announced: October 18th, less than 4 month away.

Meh. I'm not sure that's enough time. Ah well.
_________________
Mike Kasprzak
'eh whatever. I used to make AAA and Indie games | Ludum Dare | Blog | Tweetar
View user's profile Send private message
PoV
Moderator

Joined: 21 Aug 2005
Posts: 10902
Location: Canadia
PostPosted: Wed Jun 30, 2010 11:18 pm    Post subject: Reply with quote

July 1st - 3:18 AM
Added image file loading and saving support to Grid2D, via STB_Image (BMP+TGA save, +PNG+JPG+PSD+HDR load). This isn't the same thing as texture loading (of which I'm currently use a custom texture format), but instead is images as arbitrary data.

The plan was to get some sort of terrain rendering thing going, but I figured it would be a good idea if I could read/write 2D data in some known formats. I'm sure I'll eventually get around to adding PNG-proper saving, as well as support for my format (like a PNG but LZMA compression), but I just wanted a quick solution for now.

Sleep time.
_________________
Mike Kasprzak
'eh whatever. I used to make AAA and Indie games | Ludum Dare | Blog | Tweetar
View user's profile Send private message
PoV
Moderator

Joined: 21 Aug 2005
Posts: 10902
Location: Canadia
PostPosted: Sat Jul 03, 2010 7:33 am    Post subject: Reply with quote

July 3rd - 11:33 AM
I'll be diving in to Smiles stuff again on Monday, so I'm trying to get a few big things done over the weekend.

The first, Terrain rendering.



So far, I can convert a heightmap image in to points. What's not seen is that the point order is optimized for Triangle Strip generation. That's next.
_________________
Mike Kasprzak
'eh whatever. I used to make AAA and Indie games | Ludum Dare | Blog | Tweetar
View user's profile Send private message
PoV
Moderator

Joined: 21 Aug 2005
Posts: 10902
Location: Canadia
PostPosted: Sat Jul 03, 2010 8:20 am    Post subject: Reply with quote

July 3rd - 12:21 PM
Cool bug.


_________________
Mike Kasprzak
'eh whatever. I used to make AAA and Indie games | Ludum Dare | Blog | Tweetar
View user's profile Send private message
PoV
Moderator

Joined: 21 Aug 2005
Posts: 10902
Location: Canadia
PostPosted: Sat Jul 03, 2010 8:31 am    Post subject: Reply with quote

July 3rd - 12:31 PM
Now that's more like it.



The stray lines are degenerate triangles.
_________________
Mike Kasprzak
'eh whatever. I used to make AAA and Indie games | Ludum Dare | Blog | Tweetar
View user's profile Send private message
PoV
Moderator

Joined: 21 Aug 2005
Posts: 10902
Location: Canadia
PostPosted: Sat Jul 03, 2010 8:47 am    Post subject: Reply with quote

July 3rd - 12:47 PM
With Triangle Strips.



I don't have lighting or depth testing set up yet, so that's all I'm going to do with this right now (Alpha Overdrawed). Done for now.
_________________
Mike Kasprzak
'eh whatever. I used to make AAA and Indie games | Ludum Dare | Blog | Tweetar
View user's profile Send private message
PoV
Moderator

Joined: 21 Aug 2005
Posts: 10902
Location: Canadia
PostPosted: Sat Jul 03, 2010 10:32 am    Post subject: Reply with quote

July 3rd - 2:32 PM
One more. Just cleaning up the functions that do the actual drawing, now making them calculate the byte stride based on the size of the vertex type passed.



And for fun, running all 3 draw operations at once.
_________________
Mike Kasprzak
'eh whatever. I used to make AAA and Indie games | Ludum Dare | Blog | Tweetar
View user's profile Send private message
PoV
Moderator

Joined: 21 Aug 2005
Posts: 10902
Location: Canadia
PostPosted: Sat Jul 03, 2010 4:12 pm    Post subject: Reply with quote

July 3rd - 8:12 PM
Tweaking and adding functions. The generation process is now broken up in to smaller and smaller elements. If I wanted to, I could generate just the points, or just the Indexes. Also added a function for indexing in to the vertices (given the weird order they're now in for cache optimized triangle strips).



Just a test going across the entire mesh, lowering all verts in a diagonal line across (showing that both axis work).
_________________
Mike Kasprzak
'eh whatever. I used to make AAA and Indie games | Ludum Dare | Blog | Tweetar
View user's profile Send private message
PoV
Moderator

Joined: 21 Aug 2005
Posts: 10902
Location: Canadia
PostPosted: Sat Jul 03, 2010 4:46 pm    Post subject: Reply with quote

July 3rd - 8:46 PM
Added some functions for indexing in to the triangle strips themselves. Using them to pulse a red "current triangle strip" across the heightmap, mainly because it looks cool.



Okay, I've run out of utility functions to make here. ;)
_________________
Mike Kasprzak
'eh whatever. I used to make AAA and Indie games | Ludum Dare | Blog | Tweetar
View user's profile Send private message
Reply to topic GDR Forum Index -> Game Developer's Refuge -> Development Log - GEL and Foundation (Engine Tools) Page Previous  1, 2, 3, 4  Next

Use this link to get a Sign-On Bonus when you get started!

All trademarks and copyrights on this page are owned by their respective owners. All comments owned by their respective posters.
phpBB code © 2001, 2005 phpBB Group. Other message board code © Kevin Reems.