Lessons learned and other things

So yeah. I’m posting increasingly less on this blog for no real reason it seems. I generally have a lot of stuff to write about still but I have returned this time to share some insights from the past year or so.

I realized a few days ago that I’ve been writing custom graphics rendering since the early months of 2009 or so, maybe even before that. That’s only a little short of 5 years! It doesn’t seem like a long time since time flies when you’re just working away on something.

But I guess my ultimate point here is, to cut to the chase, that I’d strongly advise against coding a game engine or rendering module from scratch. That is if you can help it, if there’s another choice accessible then chances are that’s a better choice and will allow you to get into the better parts of it quicker. If you can’t help it or you really really want to code one, do it, it’s a great experience and I’ve learned thousands of things that I never thought I would have.
And I’m not going to suggest that everyone is going to have the same type of experience that I’ve had with this, I’m sure a ton of you out there are far smarter than I am and can maybe approach it with a less-than-bruteforce method.
But I’m not alone in advising against this actually, it’s one that you run across pretty quickly when browsing online forums and stuff concerning game development and such; there’s always that one kid who wants to write an entire game, tool pipeline and engine from scratch on a weekend. 😉

And right now, it’s been like maybe a year since I really sat down in the nitty-gritty and wrote some low-level rendering or engine code and I don’t really feel it’s going to come back around any time soon- at least not the writing from scratch thing, I think I’ve gone about as far as I can with that.
No if I’d code an engine in C++ again it’d have to borrow some technology from other sources, like a renderer for example. I’ve always leaned on third-party libraries for physics but it was a long time ago I used another renderer than my own.
It’s just that there’s a lot of stuff a renderer does that I’ve often found cumbersome to design and having those things already dealt with saves a lot of time and effort.

I’d like to point out again that while I think it’s a great experience to go the “hard route” and code an engine from scratch and all that jazz I can no longer say it’s a good idea (or even a sane idea) when all one really wants to do is code a game. The benefits of rolling your own engine are generally outweighed by the inconveniences of it. (Of course it depends on any given situation but generally this has to be true, if it’s not true then you obviously know what you’re doing already and shouldn’t concern yourself.)

This is a sort of disjointed ramble, but that’s my take on it right now anyway. 🙂

Advertisements

Long time no see

Wow. It’s been quite a while since I posted anything on here.

But that’s about to change. School’s out for summer and I am free to work on some of my projects more intensely now and boy do I have a lot of catching up to do.
The stuff I’ll be working on right now is the project I posted about a while back and how we should actually go about the game at all. There has been some changes which means we have re-structured some things.
I’ll get into these details at a later date on that blog itself, I’ll keep the details slim here.
But yes, I will be working on that a bunch I think, but also allocate time for other projects as well.

The past few months I’ve been spending a lot of time with my musical project which involves the use of Game Boys to make chip-music. You can read about my stuff here from time to time and listen to my “music” here. It’s actually a super fun hobby which suits me kinda perfectly. I’ve learned a ton about audio and electronics in the process which is just good. I’ve wanted an excuse to do that for a long time. 🙂

Now back to it. Programming a game that is. I’m going to post some technical stuff here later on I think… So see you then and have a great day. 😉

Some stuff

Yeah, so it’s been quite a while since I put anything on this blog. I’ve been spending a lot of time elsewhere and doing other things.

I’ve still been programming on my own engine and such in the background and working generally on experimentation and thinking (thinking long and hard) about things I could be doing differently and things that I’m doing that maybe I don’t need to and so forth. It’s extremely careful consideration work going on…

Other than that I’ve written an extension for my 2D engine project, formerly called “Junebug”. It’s now called “SpiderTank” instead. The details to this name change are irrelevant… but spidertanks are sort of cooler than junebugs. Less cute… but cooler.
But the idea is still the same… Simple and fast 2D engine. I’m right now working on ways on rendering a virtual screen resolution, to support more low-resolution games that don’t necessarily try to squeeze your fantastic full HD desktop into a sorry 320×240.
More on that later when I get it to work on a satisfactory level.

Yeah… What else… I’m working loosely on a bunch of concept projects, not going to name any of them since I can’t at all commit to them at this point, they’re way to fresh.

But mostly I just want to make games at this point, and that’s what I’m trying to do. 🙂

Project

Yeah. I’m sorta involved in a project now with some other people so there’s a pretty big chance that I won’t upload anything on this blog for a while.
Unless I want to write about something else than just engines and stuff, but most of my “programming power” will be directed towards the mentioned project.
Oh- I’m also busy with school right now so that makes for even less time to “waste” on my usual stuff.

🙂

Deferred shadowmaps

Yes. They are finally happening after all this time.

So now I’ve got fully deferred lighting, but I have CSM for directional lights and now, with the twiddling of some shader math, shadowmaps for spotlights!


There we are!
The same ol’ shadows, except now they aren’t rendered using forward rendering and therefore run about a million times faster (n-… not actually the real number).

Anyway. As you can also see the Gobos are back in action. These are actually very easy to implement once shadowing is working and vice versa.

I’ll go back to work now.

Planning a re-write…

… of some of the components within the engine that are working poorly/not at all at this point in time.

Scene Manager: Yeah, I’m going to rip out the old code and implement a new, much better system which actually allows for the basic things a scene manager is supposed to do. The old system was also very slow so I’m going to focus some on making it as fast as possible.
Frustum culling will have to be re-implemented too, it’s a tad bit round-about right now so I’m interested in making it more straightforward and “tight”.
I’m still on the fence about implementing some general purpose culling implementation. It may sound a tad bit crazy, but my engine isn’t inherently designed to take advantage of a schema like CSG or similar stuff older engines used.
The engines that support this by default have the strength of being able to freely enforce such culling techniques such as PVS or Portal rendering.
My engine doesn’t. Since my philosophy for making game worlds doesn’t necessarily follow the rules of these very strict concepts I’m going to have to figure out something else that limits the entire level from rendering at once, but still doesn’t choke the scene manager up for no reason.
A lot of times culling is counteractive and some games run faster by not culling at all. Of course this can’t be fully depended on since it depends on how the game’s levels end up looking.
My thinking is, there’s got to be some kind of rough solution that can be deployed easily within the level editor to maybe make entire sections of the level cull away based on player distance or something like that. It’s not automatic and definitely a bit of a hack, but if it’s able to do the job in these cases, I’m good.
My other thought was creating some type of intricate algorithm that runs through the entire level and generates these triggers for the level which allow different parts of the level to be rendered when the “player” enters a certain area in the level. This is kind of like PVS(I linked earlier). The difference here is it doesn’t check polygons, but entire clusters of objects or areas. It’s of course not fully planned out as you might gather from reading this explanation, so it’s just an idea.
At this point I’m not too concerned with having a solution that’s not entirely user-friendly, seeing as I’m the only user right now. 🙂

Renderer: Yes, there’s still a ton of work to be done before this is fully functional to the point where I can point at it and not feel apologetic.
The main focus I have right now is really to trim away everything redundant. This also means I’ll be removing the backscattering I posted about a few posts back. Yes, yes- turns out I don’t have that much use for it after all. For the few things that need a faked translucency, there are other options that don’t hog up precious space in the GBuffer.
* CSM needs some work. I’m actually pretty happy with how well the CSM is playing with the rest of the engine right now, but it still needs some rubbing and polishing before I can relax.
* I no longer have any forward rendered lighting at all, all the lighting is deferred right now. Still missing out on deferred shadow maps for spotlights. I’m pretty sure there are cool things to be made with that support around so I’ve got no reason to trim that off.
* I need a new post processing pipeline which actually allows for some custom made post processing. The past one had set, optional effects running one after the other in a chain. It isn’t entirely bad, but sometimes you want to do something crazy, like set the screen on fire. The user should be able to.
* Particles. Still need to implement this in a way that isn’t terrible. Right now the depth sorting isn’t working too well so there are popping artifacts with multiple emitters. Really annoying.
It’s incredibly difficult to write a good general purpose particle system, it’s kinda crazy.
* ANIMATION! I need this so badly! I’ve just not had the energy to go back and re-implement the support yet. It’s an entire pipeline that needs double-checking, it takes time. I don’t have that much time right now.

What else… Those two are pretty much the largest problems right now. There are other things, such as the Resource Manager needing a lil’ kick in the rear to work better. But the rest is working OK at the moment.
I must add that through these years of coding engines and learning how engines work, the single biggest pain in the neck is model format support. If you back-track a loooong way in this blog, you’ll eventually start unearthing the many posts I’ve made in the past that are clad in pained wails about how it sucks to not have a model format that supports basic stuff and isn’t either closed source or in some weird format that everyone wants to make into their own.
Until the point where I said “TO HELL WITH IT, I’m making my own!” and I did.
But making your own format is actually a lot harder in the long run, because when other formats have bad support or poor documentation you can have the moral high ground of belittling work someone else did, but when your own format craps out- you just march your pretty little behind to the nearest mirror and let that guy have it!

Right now my own format only supports Blender as the 3d modeling suite, but not the latest Blender version because that broke a part of the code and I need more time to re-write that exporter… again.
But my model pipeline supports some common other formats as well, such as OBJ and very partial FBX support. I want to add some more like COLLADA and ASE because those are easy to parse. So once I get the motivation I need to make all this happen, it should be much better. Animation support will always be a very difficult subject matter though and unfortunately won’t see extensive support… Unless Autodesk finds it in their hearts to open source FBX… Please?
Edit: I should clarify that the other formats are actually converted from their source formats to my engine’s proprietary format. Just making that clear.

A lot of plans… A lot of plans… I just need that “spark” to do it all. *sigh*

Bye for now. 🙂

Back in action (sort of)

So yeah.

I’ve some urge to code again after a pretty short break I guess (considering how arbitrarily long a break can be).
Something occurred to me a few days ago and I realized that this is actually a kind of smart thing to do.
I broke my mesh loading/processing/utilities into its own library. It’s way easier to manage, change or extend now that its no longer tied to a larger code base.
I, of course, realize that I could’ve done this months or even years ago but it never struck me as “enough” of code to make into its own library, but it is.
I’ll be free to re-implement the animation support a bit easier now since I don’t have to lug around the rest of the engine in order to change it.

This is really a minor thing, but it’s also the only thing I’ve done the past few days as far as programming goes.

It also makes it easier to maintain other tools that are closely connected to the mesh processing such as conversion utilities, viewers and exporters.