Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Member Since 03 Jul 2012
Offline Last Active Today, 07:53 AM

#5237415 Disk Area Light

Posted by rnlf on 28 June 2015 - 11:15 PM

Here's what I would do: First project your point onto the plane of the disk. Then check if the distance from the projected point to the center of the disk is less than the disk's radius. If if is, voila, closest point. If it is not, scale this distance to the radius of the disk, which will give you the point on it's perimeter that is closest to your original point.


Actually, I think this should be pretty close to what you have do with your rectangle light.

#5236286 Do you comment Above or Below your code?

Posted by rnlf on 23 June 2015 - 02:17 AM

Commenting around your code? ok!



Thanks to syntax highlighting this is still pretty readable :D

#5233817 I get distracted with my other hobbies when watching video tutorials. [Read M...

Posted by rnlf on 09 June 2015 - 09:34 AM

I never understood why people would prefer video tutorials for something like programming. Whenever I search for some information, I can skip through a written text with ease and find what I've been looking for and read it in my own tempo. Watching video tutorials is so much more work. You have to watch the whole video to know if your actual question was answered, you have to listen to the guy making it the whole time, watching him getting sidetracked and going off on a tangent every few minutes.


I really don't think video tutorials are any good for learning programming. I can see the use for them for more dynamic tasks like drawing, 3d modeling or music composition, but for programming?


If it's so hard for you to focus on one thing, practice that. If you think you can't work as efficiently with a written tutorial as with a video tutorial, ask yourself if you're just too lazy to read the text (or improve your reading speed!). I was similar when I was younger, getting bored really quickly with long texts, but I was able to fix that with some practice (unless you have or think you have ADHD or something, then you might want to have a doctor take a look at your situation).


Reading is a very important thing for programmers of all kinds and there will be a day when you've advanced further than any tutorial can guide you. That's the thing you should be looking forward to and working towards, because it's a very rewarding thing when you can work out and solve a complex program all on your own. You will not be able to avoid reading a lot of stuff (and learning how to skim a text efficiently) by that time. Why not prepare for it now?


As for the books problem: I think you can order books on amazon.com and have them shipped to (almost) wherever you live. It might be a bit more pricey for you, but still better than having no books at all.

#5210514 best and fastest way to understand a code written by some one else

Posted by rnlf on 13 February 2015 - 11:17 AM

unless it is a real disaster,


Even then it's helpful. You can still at least easily find functions that are leafs or very far up in the call graph.

#5210439 best and fastest way to understand a code written by some one else

Posted by rnlf on 13 February 2015 - 02:58 AM

What helps me is to let some tool like Doxygen create the documentation for the code (even if it doesn't have any Doxgen markup attached), and make sure it produces a call graph for every function/method. That way one can easily see which code gets called why what other code and it is often useful to understanding the overall structure. There is no use in understanding the details of every function unless you need to get into the details to do you work on this specific piece of code.


This has been very useful to me when searching through a 20+ million LOC project with a 25 years history behind it, so there were several generations of engineers working on it.


EDIT: Ninja'ed angry.png

#5205952 Lone Poor developer protected from Mega companies

Posted by rnlf on 22 January 2015 - 02:59 AM

The more interesting question is how to acquire an unusual idea in the first place. I feel like the hobbyist and indie world is split in two major and one small group:


Those who have unusual, cool ideas, but are unable to implement them.

Those who have no innovative ideas, but would be able to implement them.

And a very small group of those who have both. Those are the guys that can actually live off of their work as indies (if they somehow manage to get the business part right, too).

#5205565 c++ Heap corruption w/ std::vector

Posted by rnlf on 20 January 2015 - 10:14 AM

The code itself looks correct to me. Very often, heap errors happen at a completely unrelated place and show only much later. Stuff like this is usually hard to debug, but Visual Studio should help you with that.

#5191470 HTML5 / Javascript Game or Desktop (.exe) Application

Posted by rnlf on 06 November 2014 - 02:18 AM

Consider using http://kripken.github.io/emscripten-site/  It allows you to compile C/C++ to JS, including OpenGL ES. With a few tricks you can make it compile for the Web and to a native executable. Also the Web-Version ist way faster than any JS you would come up with yourself.

#5167012 How to avoid "stacks of doom" in 4X?

Posted by rnlf on 15 July 2014 - 10:13 AM

Even the supply line idea is present in MoO, but by the time it would be needed to balance the game, it doesn't matter anymore.


In MoO, ships have a limited range, based on their fuel cell technology. If a ship is stranded too far away, it will automatically return to the closest colony (which doesn't make any sense, considering that it was limited by the fuel cells, but whatever). So if you the closest colony to your currently targetted system, your attack will be cancelled. Too bad, after a while you can research better and better fuel cells, resulting in Thorium Fuel Cells which provide infinite range. So while this again limits the expansion in the early game, it is useless in the end game.


I really wonder if all these things were added in that fashion to make for more challenging middle games and quick end games or if it was actually just a balancing error.


Maybe they decided it was not desirable to have a more balanced end game because the game would get too slow paced then. That's a really interesting question for me, as I never thought about similar game design issues yet...

#5166997 What is software rendering really?

Posted by rnlf on 15 July 2014 - 09:29 AM

Depends. If your output device is a local monitor, you usually need some kind of video adapter (you could also write your renderings to a file, networks stream, printer, ...).


But if you want it to be visible on the screen, you copy (or let the operating system copy) your prerendered image to the video memory. In that case, the only thing the video adapter does is to output the image data to the screen.


In hardware rendering, you do the same, the difference is that you don't first use the CPU to do the rendering work but some hardware accelerated mechanism. But the stuff that happens after rendering is exactly the same with the same hardware parts involved. That's why it's usually (or was at least at some point) called hardware accelerated rendering.

#5166983 How to avoid "stacks of doom" in 4X?

Posted by rnlf on 15 July 2014 - 08:06 AM

ferrous: Master of Orion has something similar and it didn't stop players from stacking up. In MoO, you have command points (not sure if that's what they're actually called), which are produced by certain buildings of which you could only have one per colony. Bigger ships require more command points. If use up more command points than you create, the maintenance costs of your fleets are increased quite a lot actually. But with just a few economically strong colonies you can counter the effect by producing trade goods.


I guess Microprose had the same idea about limiting the usable number of ships, but it didn't work. At least not in the way they intended. In the early stages of the game this is sometimes a limiting factor to the speed of fleet growth but in the long run, new technologies and economic tactics make it a useless trick. Maybe that was actually done intentionally as some fort of positive feedback mechanism to make games end in a reasonable time (even single player games can take up a whole day though).

#5166962 How to avoid "stacks of doom" in 4X?

Posted by rnlf on 15 July 2014 - 06:24 AM

In Master of Orion II (one of my favourite games btw), battles take place completely within one "galactic" turn. Also there are always option to destroy a small ship without it ever being able to do anything.


I always wondered if it was possible to change the rules in such a way, that battles are not concluded within a single galactic turn (with either one fleet completely destroyed or retreated), but instead have battles last for several galactic turns (stopping after a number of battle turns and continueing in the next galactic turn). Also switching the active player after a number of unit-turns instead of after he has used up all his units' turns could make battles more balanced. That way, it would be possible for either player to bring new ships into a battle, smaller ships could destroy bigger enemies even if the enemy has the advantage of the first turn.


Also, stronger area of effect weapons that can be placed on smaller ships could help. There's for example the Pulsar in MoO, or the Spatial Compressor. Having some of those be actually more powerfull (not only more efficient) against larger fleets could counter the huge-fleet-syndrome. The strength of those weapons could also be an effective measure to balance the game towards a certain maximum sensible fleet size.


I like the other suggestions about fleet being more stealthy if they are smaller very much. Small fleets could even be made to pass through planetary defences more easily and probably even start their combat between the defending fleet and the planet if they are very small (sneaked through the defending fleet), thus allowing them to drop ground troops faster and so winning the battle without actually defeating the defending fleet.

#5132680 static symbols and linker

Posted by rnlf on 19 February 2014 - 11:00 AM

No, they are not deleted from the object file. The linker needs them to be available if a function from the same compilation unit needs them. They are just marked as local and are thus not available for other compilation units. You can check that with the tool 'nm' (i guess it is also available in mingw):

$ nm static.o 
0000000000000000 t f
000000000000000b T g
0000000000000000 D x
0000000000000004 d y

This basically means that f and y are local to static.o (lower case t and d as symbol types), while g and x are accessible from other compilation units (upper case symbol types).


It might all be a bit different on Windows though, not sure what object format mingw uses, this is an example from Linux. Learning the format of object files is probably not a very useful task. First, you barely ever need that and second, there are libraries and tools available that can already do that for you.

#5126673 prototyping c/c++ codes in easier script language

Posted by rnlf on 27 January 2014 - 02:09 AM

It's also the "usual" way to write performance critical applications or libraries in Python. You first write them completely in Python, then you profile it and whichever part has the worst performance impact is rewritten in C and exported back to Python (basically without changing this part's interface).

#5124665 Python or Java?

Posted by rnlf on 18 January 2014 - 09:39 AM

If you already started with python, stick to it. Python is perfectly fine as a language and also specifically for game development.


Java is better for Android development, but for the PC, neither has any real advantage in the sense of deployment or availability. Most people have a Java VM installed, but Python can be packed pretty small and distributed with your game (py2exe even makes an executable file from it).


Python has good enough performance for everything you might want to do in the first years (and it will take years before you can think about making anything "big").  You will also be able to transfer all your python knowledge to Java later. Most experienced programmers can pick up a new programming language in a matter of days or weeks, because they know the concepts and only need to learn how to express them in the new language.


I suggest you stick with Python, learn how to program (which is easier in Python than in Java, imho) and once you really need it, switch to Java. But that will probably not be before the end of the year or so, if you really want to learn the concept correctly.