radioteeth

The trick, for me, has been knowing that there are many ways to go about accomplishing any given task. Perhaps starting over is the key, and doing everything 'different' for once.. Sometimes I find myself wanting to implement so much functionality and so many features that programming itself becomes overwhelming. Take it easy, one step at a time. Make a basic prototyping program for each thing you want to accomplish - like drawing a bitmap, playing a sound, etc... Figure each thing out independently and integrate the solution you devise into your actual project as you go along. Some of us tend to overcomplicate things by intending to do things 'properly'. I hate the majority of available software because all I ever see is what's wrong with it and what I would have done different to make it better, but we are all just humans trying to create machines, and not machines making machines (yet). If your code/project doesn't meet your standards, lower your standards, because you (we) won't be able to do any better until you (we) are able to meet a lower standard first. If you're not enjoying yourself, then you're doing it wrong.

There is no real way to gauge performance concretely. Progress on a project cannot be measured by the number of lines of code, for instance, because that same project could be written any number of ways with completely varying code. SImilarly I believe it is a fallacy to assume anything about one's performance based on the end-user experience provided by a program, and the amount of time it took to write.. Because, again, it could be written in any number of ways (in any of the many languages, using any number of the many available development libraries and their APIs, etc).

Maybe someone could re-create what you have in 10 minutes? 20 minutes? But would it be as thorough and/or thought out? Sure, the more experience, the more efficient one (probably) becomes. My advice is to not worry about your performance, but instead program because you enjoy it. If you want to become a better coder, then simply keep in mind that there is always room for improvement in the way you go about designing software, and learn what you can at you own pace. Do it because you want to, not because you feel like you have to. Enjoy your experience.

Personally, my current struggle is being content with what I produce - I am unrelentingly second (triple, quadruple, etc) guessing everything I write, and it only stifles my productivity and enjoyment. Good luck.

In my current project I felt a definite need to invest some of my critical thinking and programming skills into this issue, and the end result was basically a kernel that divided everything up into a grid of states/systems. The X/Y dimensions of this grid are the Systems and States of the engine/kernel.. Thus, systems like Render/Network/Physics, etc. with various 'states' that can be invoked across threads, and done so repeatedly according to a desired time interval.. Eg: Render_Setup, Render_Cycle, Render_Shutdown...

Each system I allow a min-interval and a max-interval. All systems attempt to reach a 'balance' so that their actual execution intervals are within their defined ranges. If one system is running plenty quick for a particlar state (eg: STATE_SETUP, STATE_STANDBY, STATE_INGAME, STATE_SHUTDOWN) and other systems aren't, it will simply increase the wait period until the next execution..

Along with all this is a neat ability to create logic-chains, where one state - depending on the result of each system executing for that state - determines what state to progress to next. So if the STATE_SETUP fails on one of the systems, it will go to STATE_SHUTDOWN.. If the setup for all systems succeeds then it can, otherwise, progress the state to STATE_STANDBY to display a menu, or whatever.

I just create a new thread for each system, unless the system specifies that it should run in the main thread (some things like hardware rendering don't much appreciate occurring outside the main thread) and each thread runs its own main-loop that determines if/when its corresponding system should execute. Integrating multithreading into the system is probably the trickiest part of the whole deal, but the key is to not over-think it..

As far as overhead is concerned, my primary goal when devising this setup was having the ability to control the use of resources by each system so as to provide the end-user an optimal experience as far as responsiveness is concerned, by enabling the core, or 'main loop', to skip the refresh of certain systems which can afford it..

If one system magically takes a bunch of time and causes other systems to fall behind, forcing them to execute well beyond their max-interval, what I do is take the total amount of elapsed time since the last refresh (for each system, individually), divide it up evenly, and execute the system however many times in an attempt to emulate proper execution intervals so as to allow the system to 'catch up'.

I'm not sure how well I explained this, but it works great and I'm happy with it.

I believe that the actual term 'game engine' was coined by id Software back during development of their game Wolfenstein 3D. They didn't know what to refer to the game program itself, so they just called the code that compiled into the game exe the 'engine'.

Games (more often than not) consist of a variety of media, eg: audio, graphics, models, etc. The game 'engine' is what coordinates grabbing user input, and creating the actual game experience itself via the screen and speakers. This does not require anything other than creating an interactive experience through the use of programming.

everyone has great suggestions and ideas in response to your query. I wanted to point out that for many of us, we got started pre-opengl and during the early opengl. the reality is that opengl is the same that it has always been, as far as the bare minimum functionality is concerned. GLSL is only a newer part of opengl that gives programmers control over the newer GPU-programming functionalities, but it's all performed within the context of what opengl has always been. your sub-standard hardware is plenty for a beginner.

as opposed to making suggestions about what I think you should do, I'm just going to tell you that my personal experience was by mere chance guided into getting into opengl instead of direct3d, there was no rhyme or reason, but I am happy because seemingly all 3D-capable devices have some form of opengl support (whereas d3d is the exact opposite, with the exception of what I imagine to be some similar form of it on the xbox).

'opengl programming tutorials' is/are all you need, both literally, and as a google search term. I discovered nehe.gamedev.net a lifetime ago and off I went writing native win32 applications that utilized opengl. it wasn't until much later that I began using a cross-platform library, which came to be SDL, the most decent one at the time (for my needs).

there is SFML, I recently began familiarizing myself with the library's API documentation as it appeared to have such a clean and concise implementation, began a sort of practice project with it, only to find that it required some further external libraries to actually be used by my program which were not included - a personal pet peve of mine as far as software development is concerned.. these sorts of 'issues' are known as EXTERNAL DEPENDENCIES, and I hate them passionately, including all programs and programmers that RELY on them incessantly without any regard toward the end-user's experience and/or overall performance degradation that may result from them. It takes a real programmer to write quality software, and 'quality software' entails producing an OPTIMAL experience to the user.

nowadays I've resorted to hand-writing native code for each platform, basically for the reason that I simply do not trust anybody - including other programmers and their widely-varying abilities, and it's bad enough that my code runs in an operating environment that I have little to no idea what it may be doing behind the scenes *really*, there's simply no need for me to further complicate things with library API learning curves and the unpredictable issues that will only be layered ontop of the inherent and/or existing ones that development will burden me with.

but that's just me, and I felt my 2 cents were about due around here.

The option I go for is enumerating the available resolutions and giving those to the user. As far as GUI and HUD placement, I treat the screen as a 0.0 to 1.0 surface, or say 0-100 etc.. the point is screen resolution abstraction, making it independent of the resolution, or aspect ratio for that matter. So then all your GUI/HUD stuff is placed onscreen in terms of this pseudo-resolution. Naturally this incurrs some sort of 'warp' as the aspect ratio changes between screens and window sizes, but this can be resolved by using native pixel scale for the dimensions of various elements, and the abstracted resolution is only used for positioning.

At the end of the day you just have to multiply your 0.0 - 1.0 element XY positions with the screen's actual resolution to produce the actual pixel position.

There is a C variant of SFML if you dig around on the SFML-dev.org website, so you're not forced into incorporating C++ code into your project if that's your intent.

Personally I chose occasionally because there are tidbits that do catch my eye, and I eventually get caught in a scrollfest much like I find myself doing when I visit say slashdot for instance.

I'm not sure if it's just the layout change but it seems there are more actual news items now than before, which I assumed was the result of utilizing some automated system of sorts. Whether or not this is the case I do feel that I'm being offered more game dev related news than before, and it's nice to see it compressed so elegantly and uniformly, being the perfectionist/minimalist that I am. I was only disappointed that the old IOTD wasn't transferred over to the new database, but it was a relief to see that an archive of such antiquities is being kept online.

All-in-all I'm just glad gamedev exists after all these years because of the forums, which is where I spend most of my time here.

normalize your step increment vector:

float length, stepx, stepy;

stepx = Xb-Xa;
stepy = Yb-Ya;

length = sqrt(stepx * stepx + stepy * stepy);
stepx /= length;
stepy /= length;

Bullet->x += stepx;
Bullet->y += stepy;

tada!

Here's an example where it's pretty clear when to use what.
Hope you appreciate my awesome cloud painting skills

Microsoft should have hired you for their bootscreen graphic. just throw a RGBY microsoft windows swazi on there.


In my 3D projects I typically use spherical (distance) and cylindrical volumes for everything.  In Molle's example the bounding circle/sphere is set on the outer-most point of whatever object it represents the collision volume of, in my experience I try to find a happy medium because there are no simple shapes that accurately depict the collision area of any of the objects I typically use in my projects. So instead I will use a bounding sphere that is actually smaller than the model so there aren't large areas where collision will be occuring without the model actually touching anything, or sometimes combinations of bounding volumes for different collision checks. This also can result in the farther portions of the model going through stuff to a degree, but like I said it's a happy medium.

Most especially I use distance checking because you can avoid its slowness by NOT doing the square root and simply squaring the other side of the equation..


As for bounding boxes, do you really think they are really any more accurate ? They are actually slower than a distance check because the CPU is making two variable comparisons, provided that you optimize your distance check to not use the squareroot.

So for example:

 //here's your typical pythagorean distance check

 objectA.position = [1, 2];
 objectA.radius = 5;
 objectB.position = [12, 4];
 objectB.radius = 6;

 radiisum = objectA.radius + objectB.radius;
 delta = | objectA.position - objectB.position |;

 //pythag
 distance = sqrt(delta.x * delta.x + delta.y * delta.y);


 if(distance < radiisum)
  colliding();

but to eliminate the slowness of square root calls (in projects where I have many objects that I am comparing for collisions with) I would do this:

 //square-rootless distance check

 objectA.position = [1, 2];
 objectA.radius = 5;
 objectB.position = [12, 4];
 objectB.radius = 6;

 radiisum = objectA.radius + objectB.radius;
 delta = | objectA.position - objectB.position |;

 //pythag without the sqrt
 distancesqr = delta.x * delta.x + delta.y * delta.y;

 radiisumsqr = radiisum * radiisum ;

 if(distancesqr < radiisumsqr)
  colliding();

The end result is the same and I did it without a square root call!

If you wanted to get fancy, use a distance check like this between your sprites to see if they could potentially be colliding, then do a per-pixel collision check ;)  then you'd be uberleet gamedev guy.

The difference is that distance is circular in 2D and spherical in 3D, not square or rectangular like a bounding box.

So on your bottom example, those would be two circles. One with a radius of 2, and the other with a radius of 1. The pythagorean theorem determines the distance between the two as a linear value, instead of a vector of XYZ values, and that distance is used by checking if it's less than the sum of the radii of the two objects in question.

Bounding boxes check the XYZ independently, whereas distance combines XYZ using pythagorean resulting in the circular or spherical check.

www.lazyfoo.net  check out his SDL tutorials. SDL makes it very easy to make your program handle user interaction by giving you a standard set of functions (the SDL API) with which you can check for user input and set graphics modes and other things. SDL is cross-platform compatible, so it will be relatively easy to get your code to run on other systems besides Windows, and whether or not that matters to you it will greatly simplify development of your project regardless.

SDL is admittedly somewhat dated but it gets the job done. Alternatives like SFML and QT are basically the same, but newer and perhaps cleaner in some ways, but they demand that you incorporate them using an object-oriented approach, which is probably somewhat of a hinderance for someone who doesn't know much about anything.

DevC++ itself has been largely left for dead by the developer, the latest release I believe dates back to 2005, and it has bugs which will cause it to crash unexpectedly (unless you know what to look out for!) and even though I still use it to this day I recently found an awesome equivalent with some additional features (like code folding, oh god how I would have loved to have code folding in DevC++ all these years).. It's called MinGW Developer Studio, and it's very nice and compact and just as easy to use as DevC++, I almost feel that it might be based off of DevC++ itself, but it's more likely that it's a complete new IDE developed from scratch.

A lot of coders will tell you to use some professional tools like Microsoft's Visual Studio, but I'll have you know it's not beginner friendly for someone who wants to compile an EXE that will immediately run on another machine without first going in and disabling all sorts of run-time dependancies (thanks Microsoft) that your program will require end-users have installed and up-to-date.

I'm a huge fan of making my end users happy, and thus have always followed a very simple coding style that makes not only my life easier, but also the lives of my end-users happy by eliminating as many run-time dependancies and external libraries as possible. I've been writing a whole variety of desktop applications over the past decade, and I can tell you that my applications will run on any version of windows from 98 to 7, and sometimes even 95. Now I know that this doesn't matter to most, but whenever I personally download and install a program that an independent developer has released and it expects me to have very specific DLL's that require me to hunt down what the root of the problem is via google, I opt for uninstalling/deleting the program and just finding an alternate. I don't have time to hold the hands of other programmers because of their ignorance.

Anyhow, enough of this ranting, lazyfoo.net will show you a lot of the basics for using SDL, as well as getting DevC++ set up to properly link your program to the SDL libraries that you will need to be able to develop projects which use it. Don't listen to super-hyper-mega experts who have been coding forever professionally, they will suggest you take a path that they themselves did not take, and sadly they do not realize that telling newbies to do what it is that they do currently is not going to suffice nearly as well as pointing them toward the foothills of the beginner programmer's journey.

I learned the basic concept of C-style syntax from Quake back in the late 90's by writing mods for the game in the scripting language that it runs on called QuakeC. Shortly thereafter I found a copy of an old C++ compiler my father had in his storage and some Win32/OpenGL tutorials to make rainbow triangles and texture-mapped quads. Reading and playing with existing open-source projects will help you far more than asking lots of questions, this I know from experience. With the advent of google, anybody can become a programmer purely by self-teaching. GameDev.net has always been a great resource just to get answers from people who have experience in specialized aspects of coding, and developing games of all kinds, but don't expect anybody to become your own personal mentor, there's a reason these positions are jobs that people get paid for, it's not a simple task teaching someone all they wish to know.. It's far easier to fire up google and find the websites of good natured folk who take the time to write articles and tutorials. They are few and far in-between, but they are there, and there are enough of them to help anybody get started.

Remember, google is your best friend, you just have to practice your abilities at figuring what search terms will help you find what you want. Search for what you think you're looking for, and see what sort of terms show up on the results, try using those search terms because sometimes what you're looking for has a name and all you need to do is find that name with what you do know about what you're looking for.

Good luck, and stay motivated and positive, don't let anything discourage you but try to develop a realistic sense of what you can do in a time frame that won't cause you to lose your job or fail your classes, etc..

Oh, and don't get mad at anybody who isn't willing to help, or tries to insult you, it's not their fault you have dreams.

instant gratification is the key to success.