Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 04 Jan 2013
Offline Last Active Oct 19 2016 09:16 AM

#5263106 C++ and C#

Posted by on 22 November 2015 - 04:06 AM

I did not try it on Win10, but anyway:


If you only want a command line compiler: http://mingw-w64.org/doku.php/download

There you can get an IDE to use it with (or optionally IDE with another compiler version prepackaged): http://codeblocks.org/downloads


Or if you'd like the MSFT IDE+Compiler instead: https://www.visualstudio.com/en-us/products/visual-studio-community-vs.aspx

#5263104 C++ and C#

Posted by on 22 November 2015 - 03:42 AM

Every decent OS has a compiler. It would be stupid to run an emulator like DOSBox just to use an outdated DOS-compiler, when there are better compatible modern compilers (GCC, clang, MSVC).

#5259235 The wrong way to count lines of code

Posted by on 27 October 2015 - 03:44 AM

LOC is clearly an outdated metric. Its weird that people go to the effort of counting lines while each counting differently.

I'd suspect making a .tar.gz of all source files and comparing size in bytes might be more useful for comparing project complexity, but still flawed. At least it would condense obvious bloat like copy-paste and extraneaous whitespace, which you could then find out about if the .tar significantly increases in size but the .tar.gz not.

#5258801 How to cope with code in different languages?

Posted by on 24 October 2015 - 04:59 AM

One of the main reasons for you to rewrite the game code seems to be the Delphi IDE. Why dont you try using Lazarus/FreePascal before you start rewriting everything in C++, its free and I read its striving to be compatible with many older Pascal implementations?

Also, it seems you can do function calls from one language to the other, which means you could just keep it that way. Just try to move a few parts when it allows you do have a smaller cross-language API? Then if you want to move some part to the engine you could only reimplement that part in C++, not everything.

#5258800 Why didn't somebody tell me?

Posted by on 24 October 2015 - 04:12 AM

And its time-proven practice to always use parentheses in defines to not be surprised by operator precedence from combined expressions.

#5258635 Looking for feedback on menu system design

Posted by on 23 October 2015 - 03:06 AM

Once I wondered why there had been so many activation sounds. I guess you were just frantically clicking when the menu item was already activated?

I would only play a sound when activating a menu item, not on each click, and hava another sound for highlighting.

#5258522 Help with specs for laptop

Posted by on 22 October 2015 - 09:36 AM

I think the most important thing to not cheap out on is to get a newest generation CPU and graphics chip, because you will curse yourself in a year or two if you can not test properly as your computer does not support a newer version of graphics API or instruction set you want to use.

An extra graphics chip is nice cause Intel is the fastest to stop supporting older chips with the drivers, AMD and NVidia often support a higher OpenGL or DirectX version than Intel and its nice if you can test 2 of the 3 vendors implementations on a single machine. Watch out if you buy an i3 or i5 that sellers often just advertise that and forget to tell you they put an old i5 3xxx inside.

You can always live with having a slower CPU/GPU/HDD or having not a huge amount of memory to save on money, but you might want to check if there is a free slot when buying a 4GB computer (which is still ok atm).

#5258480 Managing large amount of data.

Posted by on 22 October 2015 - 02:21 AM

You could conceptually cut the world into larger areas, have each area save its own array of changes and only search areas visible to the player for rendering.

Why don't you try a longer game or generating a large changelist and then profiling before deciding if its worth optimizing?

#5258329 OOP inheritance structure

Posted by on 21 October 2015 - 08:58 AM

Thats the usual problem with large inheritance trees.

You better have a separate AI object, which gets a reference to the Entity, then calls its methods to control it. You don't need to create one AI class for each object, as they should provide the same API.

Other parts you can cut out of the Entities and have them contain subcomponents which handle certain things or try not to use new classes when you can just have some data.

#5258069 Why didn't somebody tell me?

Posted by on 20 October 2015 - 04:10 AM

To me its intuitively clear, that when you have a pointer type the const applies to the pointer.

#5257974 Does calling ~myclass() (destructor) deletes the object?

Posted by on 19 October 2015 - 02:29 PM

That is why you should follow the rule of 3/5 and fix your texture class to at least have correct copy contructor, operator= and destructor.

#5257650 How to handle Monster AI w/ Player Positioning?

Posted by on 17 October 2015 - 04:18 AM

Why update hundreds of enemies when there are only a few onscreen?

Only update what can be seen by the player, this also prevents some cheating.

#5257446 Why didn't somebody tell me?

Posted by on 16 October 2015 - 02:25 AM

They may just not care, and might additionally know there are enough better, free replacements?

#5257444 Adding some GUI to OpenGL

Posted by on 16 October 2015 - 02:06 AM

This is the original video, which started the idea of IMGUI: http://mollyrocket.com/861


The Nay-sayers in that thread on stackexchange only seem hung up on some supposedly bad bundling of logic and rendering from their view of only knowing entangled RMGUI, cause one person answering called his example functions RenderButton and so on. They are not considering how these are implemented internally (probably only the clicking and positioning logic and then calling into some helper function to put drawitems into a renderqueue).

Both do basically the same drawing, but the RMGUI tries to only update changed parts.Then if some of your game objects changes you have to find the right GUI objects which you have to update, calculate update rectangles (and inevitably forget some) to invalidate some parts and hope that the listeners are set up to propagate all changes to the subobjects. RMGUI is an entangled mess of observer-objects which never know when/if their listener methods get called. If you are lucky all necessary draw methods get called timely and necessary parts of the screen updated, though nowadays all that complicated logic is useless, you redraw the whole game window for the game world and a few extra rectangles for the GUI wont kill a modern GPU. If you would just invalidate everything to ease your work an avalanche of update events would ripple back and forth through all GUI objects.


With IMGUI you most likely just do a little setup each frame, no update checking needed, just call the functions for the GUI elements you need and check for results returned from them. The generated drawitems can then be rendered however you like when you think its a good time (for example after rendering the game world). At least thats how I did it when I wrote a little IMGUI library for myself some time ago.

#5257183 I'm having trouble making sense of these performance numbers (OpenGL)

Posted by on 14 October 2015 - 02:57 AM

You have tiny subpixel triangles and small number of vertices per object in your micro-benchmark, so you probably hit 2 bad scenarios for the GPU at once, according to these articles I read some time ago: