next »

[diwil]

The past years have been busy for me, advancing my career as a professional software developer, but due to recent events (and partially because of insomnia, damn you racing mind!) I began to work on a project I've had in my head for... The better of 10 years. I told people I'd got around it eventually.

So, as I've been programming with PHP for the better part of the last 6 years with huge success, I decided to finally start my game project. Or, in fact, several. You know, start with the small fish to get to the big ones! :D

So, after a few months of re-learning C++ and picking up OpenGL along the way with the help of various websites, I'm beginning to reach the first stable version of my 2D game engine; Yggdrasil.

The features go as follows:

• 3D accelerated 2D graphics via OpenGL, for cross-platform compatibility
• SDL for input and timers (but may change in the future if I discover a better alternative or get around to writing a specific implementation on all 3 major platforms)
• extremely simple-to-use end user API, so developers (currently just me) can concentrate on what's important; the game design
• automatic garbage collection (no more dangling pointers!) and a multitude of features to make the designer's life easier
• full Lua-scripting
• ...and much, much more to come

I still have no idea if I'll release the API publicly for people to use once I'm satisfied with the results, which depends entirely on the demand for one. I also have a series of YouTube tutorials planned for covering some of the techniques I've used, so people may learn from my mistakes and see the whole refactoring process went under.

Some of the issues I've tackled with have been OpenGL's limitations upon loading arbitrary-sized textures, as I didn't want to always allocate a 1024x1024 sized texture for a 640x480 sized screen, not to mention the difficulties with loading a HUGE_NUMBER times SCREEN_HEIGHT sized parallax scrolling background from a single file. For this, I've written a simple Bitmap class that's used as the main graphical resource in the engine, and handles slicing the original bitmap into bite-sized textures and handles painting the slices automatically, complete with cropping capabilities.

Currently the engine runs perfectly fine with OpenGL 1.1 specifications, as I want it to work perfectly fine on near-ancient computers, but still being extendable enough to support the cooler things the modern computers have to offer via pixel shaders and whatnot.

The initial performance tests have been quite positive, both on my desktop computer (low modern specs) as well as my laptop (very low specs) giving me ~150 FPS with 4000 clipped sprites (from a sprite sheet) on the screen simultaneously, without any of optimizations I have in plan to implement (like in particle systems, where 4000 isn't really much), via vertex arrays/buffers and other small tweaks to the code.

Pretty much everything in the code is written by myself, as I wanted to keep the dependancies low, so I had to write my own implementation of FreeType for text rendering, among other things. It's been tedious at points but the reward of learning new things has made it worth every excess cup of coffee.

The first game I will be testing with this will be a puzzle-platformer with this little fellow as the main character:

Mind that the sprite's a rough first draft and intentionally left very low-res.

[muku]

Man... I used to be just like you, suffering from a bad case of "not-invented-here syndrome", feeling the need to have control over every last line of code in my projects. Luckily I've got over that a bit and I now use support libraries liberally because, frankly, when I'm trying to make a game I couldn't care less about how jpegs are decoded. Not that I don't find these things interesting, but at some point you just realize that these problems have all been solved, and solved well, much better than you alone could do in your limited spare time, and if you want to get a game done you're well-advised to make use of that preexisting know-how.

But that's not to detract from your achievement (and actually I don't use a preexisting 2d engine either). At the very least it's good to know how such things are put together internally.

Finally, that sprite looks cute already, and I'll be looking forward to hearing more of that puzzle platformer of yours

[diwil]

Thank you! :D

And yes, I know using ready made libraries for everything would save me some time but like I mentioned in the Mandatory Introduction Thread, it's just one of my quirks as a programmer. I have no problems with using ready made stuff when collaborating with people, but when it comes to my own personal projects, I prefer to do everything myself... However, thanks to many years of PHP, I've learned the good practices of OOP, so I pretty much recycle code around every project.

I mean, some stuff I've ported from certain PHP projects of mine, which just happened to be suitable for the task!

But as I'm still giving the engine itself the last few polishes, I won't get down to gameplay until later this week...

Good thing I have that panda bear pretty much fully animated, down to several idle animations and death! I was wondering, however, if to make him more... Less gameboy-ish. I guess I'll see about that, once the game starts shaping up.

[Decipher]

Horray for navnen på norsk!

[diwil]

Ooh, another Finn!

[diwil]

I figured it was time for a small update on the engine department, as I've been working on cleaning up the code and adding a few last features in!

So, this week I've been mostly working adding TrueType font rendering support via the wonderful (and complex) FreeType library. I still have kerning and such to fix in the code, as I didn't want to use the GLFT or GLTT libraries for, well, the way my engine is organized, plus I wanted to learn how the FreeType library works. It currently supports automatic creation of font-sheets for any size, in both regular anti-aliased format and monochrome, and I plan to add in border rendering for obvious reasons.

After this little step is done (tonight), I'll start working on the Panda game's logic... So, screen shots are coming in a day or two.

[OryBand]

Good luck on your project, lynchpin.

Be glad if you'd post some screens showing your engine's basic abilities and such.

This is very similar to what I'm trying to accomplish, so I would be very glad to read your dev journal \ post-mortem \ youtube-thingies when you'll have them ready.

Thumbs up!

[diwil]

Will do. I never really like to show anything unfinished to people, so I'm keeping it in the wraps until I have a proper tech demo going on.

But, like I said, this weekend I'm gonna code like there's no mañana!

[Movius]

I'm very interested to see how this turns out.

I've been working on a lua-scripted 2D engine (written in C++/SDL) in recent months that seems like a much simpler version of what you've done. Unfortunately my effort has turned into a disorganised mess, good to see someone have more success.

[diwil]

Yay, I just finished improving the automatic memory management, by implementing smart pointers with reference counting, so pretty much everything is now automated when it comes to dealing with my framework's basic classes, such as bitmaps, fonts and sprites.

The engine design relies heavily on object managers, sort of factory classes that hold an index of every single object of their type, and when requesting for an object, it returns a smart pointer that'll keep itself in check. Whenever something isn't used anymore, the resource notifies the manager before it destroys itself, thus removing itself from the manager's list as well.

Now, I can do lazy-loading of sprites and have them dynamically free themselves as well, when no longer needed!

[mildmojo]

Man... I used to be just like you, suffering from a bad case of "not-invented-here syndrome", feeling the need to have control over every last line of code in my projects. Luckily I've got over that a bit and I now use support libraries liberally because, frankly, when I'm trying to make a game I couldn't care less about how jpegs are decoded.

It can be difficult to find support libraries that function on the big 3 platforms.  The all-in-one devkits usually support one or two platforms really well, but have quirks on the other(s).  Keeping dependencies to a minimum can be a cause or an effect of your development strategy.

Of course, if you're only targeting a subset of those platforms or if you're willing to maintain separate platform-specific codebases, you can use all the dependencies you want. 

[muku]

Man... I used to be just like you, suffering from a bad case of "not-invented-here syndrome", feeling the need to have control over every last line of code in my projects. Luckily I've got over that a bit and I now use support libraries liberally because, frankly, when I'm trying to make a game I couldn't care less about how jpegs are decoded.

It can be difficult to find support libraries that function on the big 3 platforms.  The all-in-one devkits usually support one or two platforms really well, but have quirks on the other(s).  Keeping dependencies to a minimum can be a cause or an effect of your development strategy.

Of course, if you're only targeting a subset of those platforms or if you're willing to maintain separate platform-specific codebases, you can use all the dependencies you want. 

With the caveat that I rarely compile games outside of Windows, I think SDL and its support libraries are pretty portable, aren't they? So is Freetype, and so is OpenGL (modulo OS-specific initialization which again is handled by SDL). That already covers a lot of my needs.

[diwil]

Yeah, that's one reason why I like to keep my dependancies low; I intend to port my engine fully to Mac and Linux (currently developing the Windows binaries), along with any games I create with it.

Also, because I dislike having to download a dozen obscure libraries on Linux, just to play a game; I'd hate to inconvenience my players the same way.

[mildmojo]

With the caveat that I rarely compile games outside of Windows, I think SDL and its support libraries are pretty portable, aren't they? So is Freetype, and so is OpenGL (modulo OS-specific initialization which again is handled by SDL). That already covers a lot of my needs.

SDL is great, but it doesn't do a whole lot on its own without adding modules.  In my case, I had a tough time finding a precompiled Windows binary for the SDL_gfx module that does things like sprite scaling, zooming, and basic drawing primitives.  The rest of the modules had DLL binaries available from their authors, but that most useful one did not.  I scraped one out of some other project or web site to get by.  Since it's so modular, SDL is probably a YMMV experience.

I haven't worked directly with Freetype yet, but the impression I've gotten is that it's low-level to the point of needing to know how to decode a font and needing to build strings by hand out of individual glyphs.  I'll admit I didn't get that far into it because I found a higher-level library (FTGL) that fit my needs.  I'd love to be wrong about Freetype because I know it's everywhere.

OpenGL is useful and ubiquitous, too.  I've started using that now.

I guess I was thinking of higher-level libraries or frameworks, or things that do more than just input and getting you a GL context.  Like, say, landscape generation, or image processing.

[diwil]

SDL is great, but it doesn't do a whole lot on its own without adding modules.

This is something I realized very early in the development; I wanted to do a 2D game with great particle effects, but the features SDL provides natively are extremely lacking; I had to write my own routines for saving PNG files, as well as cropping images due to blitting an alpha-blended surface on an already zero alpha surface resulted in another zero alpha surface.

I already had a basic OpenGL based blitter going, so I figured to postpone the game development process and add the necessary features for my own engine, which exceeds SDL and Allegro in both features and efficiency.

I was going to try out GLFT today, but I couldn't find any binaries for my compiler (Mingw32) and wasn't arsed to build the library from scratch, which would have meant yet-another-dependancy for my project... So I wrote my own font routines, which work quite well. I've yet to add font kerning, and fix a few bugs here and there but so far it does what expected (currently just displays the frames-per-second and other info).

I'm still in the midst of cleaning up the code, as I've done some major architectural changes today which obviously made the code a bit harder to read, but after that and a few little features I'll get down to making the game. It's around 3 AM right now, but I figure I'll be coding until the sun rises.

[diwil]

First public screenshot, showing the developer-mode console with logging, and the first rudementary level!

...Now to work on the collision detection...

[diwil]

Call me crazy, but instead of starting to prototype my game with simple objects, I decided to take the long route and implement the objects in the game the same way Quake handled it's entities; a solid base-class for all entities, with pointers to Lua functions to call whenever something happens.

This will probably add at least a few weeks to my development time, but I'm not in a hurry here, and I want to make the engine properly. I did a little bit of testing last night with classes being manipulated outside of the C++ scope, and it worked beautifully, and which is why I decided to take this approach for my engine.

The good thing is, once I've established the basic entity system, I'll no longer need to wait for compilation to test, and I can modify the scripts while the game is running and reload them with a press of a button. Certain things I'll keep in the game engine for performance reasons, such as the physics core and drawing, but all of the global (and per-entity, personal gravity!) variables can be tweaked from the scripts.

So, I guess there won't be many screenshots in the next few weeks but... I'll keep you guys posted whenever I'm closer to the first alpha.

[Hideous]

That's a high FPS you have there :D

[diwil]

Thank you! It would be a little bit higher, but the way I've implemented resource management eats away a little on the performance. But considering I never have to call new or delete ever again, I'm pretty sure it's a small price to pay. :D

But then again, I've yet to implement batched drawing by vertex arrays/buffers, which should increase the FPS a bit higher... But that's something I'll add later.

[muku]

Since I just spotted it in your console screenshot: how do you do pixel scaling? For Healthy Wave I just went the quick/lazy/most compatible way of doing a glCopyTexImage2D every frame and rendering the resulting texture onto a quad with nearest-neighbor magnification. glCopyTexImage2D has a reputation for being slow though, but performance wasn't much of an issue with that game. (Looking back, I could have used glCopyTexSubimage2D which is supposed to be a bit faster, but whatever.)

So, do you do something more elaborate like using Pixel Buffer Objects, and do you fall back to the method described above if that's not available?