Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 19 May 2007
Online Last Active Today, 11:26 AM

#5131298 Auto update systems - yes or no

Posted by achild on 14 February 2014 - 10:01 AM

Hey everyone. I want to put an auto-update system in some software. The question is, how will others feel about it? Why doesn't all software have this? Chrome seems to auto-update (and disabling it isn't obvious). No one seems to complain. But then other modern software will simply tell you there is an update available and redirect you to their website if you so choose. I suspect there are a variety of opinions out there on this so...


How do you feel about auto-update systems? Intrusive? Convenient? Like/hate/don't care either way? If you dislike them, what do you prefer?


Interested in everyone's thoughts on this.

#5115968 Help me get rid of this goto!

Posted by achild on 10 December 2013 - 01:03 PM

You weren't missing anything. It's just an exercise in refactoring, which is something you simply have to get experience in (like you are right now).

#5115909 Creating a game with Open source/Middleware engines?

Posted by achild on 10 December 2013 - 08:47 AM

It's not only feasible, but highly recommended you use pre-existing solutions (until you find for certain they won't work). These ought to help:




http://content.gpwiki.org/index.php/Game_Content_Resources (pre-made fonts, icons, sound fx, etc)

#5114664 2D Rects collision problems

Posted by achild on 05 December 2013 - 01:14 PM

Google "separating axis theorem".


For rectangles it's very simple.

// Assuming left right top and bottom are not flipped or invalid
if (r1_left < r2_right && r1_right > r2_left && r1_top < r2_bottom && r1_bottom > r2_top) 
    return true;  // Collision
return false;  // No collision

[edit] - I suppose if the edges are equal they would be touching but not necessarily colliding.

#5109568 2D Windows 8.1 game development C++

Posted by achild on 15 November 2013 - 03:01 PM


Other : MonoGame (http://www.monogame.net/)



I'm glad I asked, hadn't heard of that...



Except... the question states C++...

#5098326 Maps or level editors

Posted by achild on 02 October 2013 - 01:20 PM

- For something like pacman you may get away with manual input. Better even to have an external text file of some kind.

- Ideally using a preexisting solution would be best because you can get to work on your game.

- If, for some reason, you can't adapt it to your needs and you can't adapt your needs to it, (or you need in-game level editing) rolling your own will also work but will take at least twice as long as you think it will.


Tiled is fairly well done and pretty popular. There are others if you look around, depending on your needs.

#5098054 [Solved] Crossroad. HGE or SDL?

Posted by achild on 01 October 2013 - 07:44 AM

HGE is more high level and you can make games faster. I'd stick with that if cross platform is not a concern.


When you get into 3d stuff you will need to change but that's okay... HGE is very good at 2d and that's a good reason to stay with it. Once you go 3d, you may consider looking for another high level framework or even one of the engines out there such as UDK, Crysis, or Unity, really, if your interest is in making the games themselves.


People tend to build engines/frameworks on top of SDL versus using it directly. For example someone ported HGE to be cross platform and they built it on top of SDL.

#5094996 Is Win32 API sufficient to make a user interface like the latest Visual Studio

Posted by achild on 18 September 2013 - 01:24 PM



This UI in particular is possible, because you don't have text-over-image or text-over-gradients.

I'm not sure what you mean here, both are pretty simple.



What I mean is that functions like TextOut and DrawText seem to be drawing solid color background. I might have missed something, but the last time I tried, I couldn't figure out how to draw text on an image without that solid color background. I spent a few hours trying different thing. and I finally ditched DPI. If you have solid background, it is trivially easy to draw text.





(Also it's GDI, not DPI wink.png )

#5092750 Initialization Objects

Posted by achild on 09 September 2013 - 10:47 AM

Maybe not such an issue with a simple display class, but once your GUIs become any more complicated it can be a problem. With that said, generally your class should never ever be in an invalid state.


For Window to work like this there are a couple things to consider:


1) If Window is a member of, for example, an application class, you don't want it to automatically create a window just because you created an application instance. You want to have control over when the window itself is created on screen - perhaps you need to be able to load settings etc before creating it!


2) However, you don't want Window to be in an invalid state, so it is important that the Window instance has functionality to work even when a win32 window is not created. A function such as IsCreated is necessary, and internally there should be a mechanism to warn the user/error out/assert/something if you try to do stuff with a Window instance when a window is not created. It still won't feel completely solid, but it's not unheard of for GUI components.


3) The other possibility is to make it create the actual window in the Window constructor, and limit yourself to only have Window be a member in classes through use of a smart pointer (unique_ptr or shared_ptr usually). Now you can have the best of both worlds, code-wise, creating them only when you're ready and the object is always invalid (assuming no failure during window creation......).


Normally the problem is not so complicated. You simply create an object and it is valid. With resources such as GUIs and images/textures it can be a bit confusing to get right. It's also worth noting that in languages such as C# there are rules which make it much less natural to have invalid objects, and this seldom becomes a question because you usually have something that looks similar to #3.

#5091395 Why are static variables bad?

Posted by achild on 03 September 2013 - 01:46 PM

Static variables are fine at times. Do consider multithreading though, as they are inherently NOT thread safe...


As for the posted code... it has problems which highlight some dangers with your usage...


What if there is more than 1 game engine?

What if the user did not instantiate a game engine object before calling GameEngine::resourceModule-> anything? That static value could point to anything at all.

What if GameEngine is destroyed or goes out of scope? Our static variable is now pointing to invalid memory...


There are surely more issues here. So, a big issue with static variables is that they are hard to safely control....


[edit] Perhaps a good rule is not to use static variables just for perceived "convenience". Use them because they fit the problem... which you'll find is not very often.

#5082554 Why XML is all the rage now?

Posted by achild on 02 August 2013 - 01:22 PM

YAML is taking off? I have yet to see anything use it. JSON though, yes, it seems that lately everybody and their dogs are using JSON now. Probably because we're in full HTML5 mode, and JSON data is valid javascript, so using it is a non-brainer as you don't even need a parser (I wonder if anybody understands the implications of loading data as code though).


Personally, I prefer INI files anyway (well, INI-like at least). Yeah, call me old-fashioned, but they're a lot easier to deal with. XML is good when you need tree-style nesting, but most of the time you don't, really (and even then, those using XML more often than not abuse it resulting in ridiculously complex formats for no real reason).


Added systems for localization AND fairly comprehensive theming in a single night for our next release... using ini files. Still need a good sit-down or two to link remaining text, gui elements, etc to these systems, but the functionality itself is complete and works great.


Honestly I've been paranoid that the design choice was naive or missing something critical because it was so darn simple and ini files are all but unheard of these days - but it works like a charm! Not to mention it takes like 30 lines of code to have a cross platform ini parser.


I can definitely see the need to support human readable hierarchies in some cases, but it seems to happen way too often when it is unneeded.


I hold the firm belief that given time, the open-source world will achieve its ultimate goal of reducing every piece of software in the world down to operations on a key/value store (see the rise of plist, JSON, Lua, and NoSQL).


Then we can resurrect the INI file, and be done with it.



#5071874 Cleaning and 'improving' your code (const)

Posted by achild on 21 June 2013 - 02:11 PM

It needs to be in the implementation too.


May I give a small piece of advice, based on 15+ years writing code? What you're doing, making things const correct, some will argue it is a waste and even const itself is bad, others will argue it is good and makes it safer. That is a matter of opinion, both sides having reasonable arguments, but if you feel it makes it better and safer for the way you program, then hey it's probably a good idea.


However, this can easily become a thing where you start renaming all your variables/functions/macros/etc EVERYWHERE to conform to some standard way of naming things.


At first, this seems good, so things are consistent, and also once you have decided to do so it is easy to get OCD and require it everywhere. However, the problem is that if this happens to you, down the road, you will inevitably change, again, how you feel things should be named, for clarity. Then what, redo all your source code again? But now there are 100s of files instead of 10s. And so on.


One of the best things I learned on this topic was to simply work on the file that needs worked on, and keep it consistent with how it already is. If a file uses a naming convention where all variables are camelCase, stay with it so the file is consistent. If another file uses CamelCase, because you changed your mind one day on what looks better, use it... on that file, but not on the first one. Otherwise you will drive yourself crazy as your style and preferences change. Consistency doesn't have to be project wide when it comes to arbitrary choices like this (I'm not really talking about safety or smart design here, just style preferences), in fact it will be impossible once you start introducing third party libraries with their own styles. But, it should be consistent within a same source file. Now you won't go crazy.


I realize that is not what you are addressing here... but from experience I can say how easy it is to become that, so you might as well get the advice now.


[edit] That is what I am talking about, what is mentioned in the next post. Naming conventions are a good example. Keep it consistent within a file. And yes, if you prefer warts on your names, probably rAge for a reference versus pAge for a pointer, or you know, whatever you like.

#5012907 2D Image error correction algorithm(solved)

Posted by achild on 20 December 2012 - 02:14 PM

Connected Component Labelling is what you want. It is often the basis for many kinds of image analysis. In your case each pixel will be labelled, and you can just measure the area as you label it. For instance, you may keep a vector or map with each label as the index, and increment the area count as you go. Or maybe you could just detect it after the fact - whatever is easiest for you since performance isn't super-critical.

At work we use a super optimized blob detection algorithm. I'm working on something on my own time that, when importing textures, automatically detects where the various textures are on a single image. It uses a customizable flood fill algorithm. The wikipedia article on connected component labelling also has Union-find in it's see-also section, as alvaro mentioned.

You can simply determine the area as you label, whichever method you choose, and if it is too small, I dunno, refill that area with the data from one of the other perlin noise layers bordering it? Not sure how you are getting the image exactly but you'll know the area you need to "fix".

#5012467 Once you go OO, you never go back?

Posted by achild on 19 December 2012 - 09:31 AM

As was mentioned - remember it's one of many tools, and tools, while they can be typically used for just about anything, are usually specialized for certain things. (I could go cut a board in half with a screwdriver, given enough time, but better to use the saw for that and use the screwdriver for what it's meant for.)

OOP tends to be a good fit for self-contained black-boxes that don't (usually) know about the inner workings of each other. This allows them to be highly reusable for many situations. A fantastic example is a GUI system.

Procedural programming tends to shine when it comes to algorithms and complicated ... procedures. Take code for reading/writing JPEGs for instance. I've seen this done with minor use of OOP (by Intel, in fact) and it was very awkward. I've also seen it done fully procedurally, and it is just easier to follow.

Data Oriented Design is another way of thinking that is getting a lot more attention lately (it is nothing new though). This has more to do with layout and memory structure being the first thing on your mind, and so can then be wrapped up in whatever little package you want, whether it is using OOP idiom, PP idiom, or something else.
(Note that just because you use SoA does not mean it isn't wrapped up in a nice neat little object)

There's also functional programming, stack based programming, event based programming, etc... but most of all you will find what works best and what doesn't - and more importantly why, as you get more experience. So even if you just keep doing what you're doing, and pure OOP comes back and bites you hard, it's good - that's how you must usually learn!

#5012083 C++ Engine Layout

Posted by achild on 18 December 2012 - 09:29 AM

Maybe it's time for some experiments, I'll try to break the dependencies to a bare minimum as suggested by L. Spiro.

This is the most important part. Now that you have a few different advices from people, there is really no way for you to know which is the best advice until you try them. As you pick one and implement it, you will inevitably encounter issues and see problems with your solution. At this point you may realize how to tweak it, in some cases, or you may realize that a totally different solution was much better. More importantly, you will better understand why some things are bad and why some things are good. A few years later, that understanding may change too Posted Image

Have fun man! Posted Image