Jump to content

  • Log In with Google      Sign In   
  • Create Account

Zlodo

Member Since 05 Jan 2009
Offline Last Active May 20 2016 02:42 AM

#5283543 SpriteFont render Umlaute

Posted by on 26 March 2016 - 06:24 AM

You can just replace the line

  char c = s[si];

in draw() and measure() by

  uint8_t c = s[i];

 

The problem with the characters still being wrong is probably an encoding issue.

Using one unsigned char like that for accented latin characters would work if your input string was encoded in ISO 8859 format, but nowadays it is probably UTF-8. It depends where your string comes from really, if it's directly from the C++ source itself it may be encoded as pretty much anything depending on the compiler.

But it's likely to be UTF-8, which encodes all characters with a code higher than 127 as two characters.

https://en.wikipedia.org/wiki/UTF-8

 

So (if your text is indeed in UTF-8) you have to decode that to get the proper character codes. It's pretty easy to do but there are also libraries around (such as http://utfcpp.sourceforge.net/) that can do it for you.




#5283489 SpriteFont render Umlaute

Posted by on 25 March 2016 - 06:27 PM

char, for historical reasons, is signed. So if you put a value above 127 in a char, it actually becomes a negative value.

 

So with start = 32 and end = 154, you actually have start = 32 and end = -something, and then everything blows up.

 

Specifically, it's probably that which causes the crash:

        _regLength = ce - cs + 1;  // _regLength = -something...

glm::ivec4* glyphRects = new glm::ivec4[_regLength]; // ...which is probably cast into an unsigned here, yielding +a gazillion, making the allocation fail, leaving you with a nice null pointer in glyphRects

 

The solution is basically to avoid char whenever possible and use uint8_t instead. When you read characters from a string (which are usually char), cast them first thing into uint8_t before doing anything else.




#5270043 Criticism of C++

Posted by on 08 January 2016 - 07:27 AM

I just want to point out that it is not really fair to characterize the c creators as lazy. You have to keep in mind that they wrote the first c compiler in assembly, on a pdp-11 (https://en.m.wikipedia.org/wiki/PDP-11), which had memory measured in kilo bytes and CPUs that were probably slower than the cheapest micro controller on the market nowadays.

A lot of thing that may sound trivial for us nowadays with our multi core cpus running at frequencies measured in gigahertz might have been incredibly expensive back then.


#5269214 Criticism of C++

Posted by on 04 January 2016 - 10:18 AM

If that is something that makes the language unviable for you, use a different one.

Can we not have a civil discourse on the pros/cons of a language without resorting to this?

I fully agree with that sentiment. "Use a different language" is a defeatist approach that seem to assume that languages are immutable things that can never be improved, or that what we have now is as good as it gets.

Complex applications such as games often have many different parts that, with the "use the right language for the job" mantra would call at a minimum for using one language for the tools, one for the engine, one for the high level scripting. Perhaps even yet another one for ui scripting such as action script or JavaScript.

The downside is that you end up writing heaps of glue code to interface together things written in some different languages. Or at least, heaps of interface descriptions for tools to generate the glue. Or ugly macros, or whatever else you use to work around the lack of a good introspection system.

I wrote a lot of tools to do this kind of things over the years, I have came up with solutions that I find sufficiently elegant, but I still find it generally clunky.

And regardless of how much you automate it, it is always much uglier than necessary. The impedance mismatch between all the languages result in interface APIs whose semantics are always unnatural to some extent for the language in which they are exposed.

It also makes refactoring much harder. Want to move this bit of logic from here to there? Oops, you moved to a country that speaks a different programming language. Time to rewrite it.

There's something to be said for the simplicity of using the same language for everything. Or, at least fewer different languages.


#5243795 Pass anything as constructor without varargs

Posted by on 31 July 2015 - 08:08 AM

You can do this natively in c++ using rtti.

There is an operator called typeid (it's an operator that looks like a function call, like sizeof).

It returns a type_info object. It implements a "before" function that defines an ordering, so you can make a wrapper class to use it as a map index with an overloaded < operator.

C++11 directly provides such a wrapper class, called type_index, that can be constructed from a type_info and can also be used as a key in unordered_map and unordered_set, as there is a specialization of std::hash for it.

typeid can be given a type directly as in typeid( int ) or an expression. If the expression is an object instance with a vtable (such as an interface class), the type will be determined at runtime (by reading a pointer in a special slot of the vtable, so there's virtually no memory overhead). In other cases it is resolved at compilation, just giving a poiner to the appropriate type_info object directly.

Note that it is a common belief that rtti is evil and costly and should be disabled in games. I never understood the rationale for it, in particular in cases where people then go out of their way to reimplement a similar but unwieldy type identification system by hand.


#5237739 Easy source control for educational uses?

Posted by on 30 June 2015 - 03:20 PM

I've always wanted an excuse for using Fossil smile.png

 

Besides having a cool name, it is designed to be self-contained and simple to use, while still being powerful enough to be called a full featured versioning system.

A comparison between Fossil and Git here: http://www.fossil-scm.org/index.html/doc/trunk/www/fossil-v-git.wiki

((Totally biased comparison, of course, but nonetheless...))

 

I especially like that Fossil has wiki and issue tracking built right into it.

And that great care has been taken to ensure that you can't shoot yourself in your feet so easily.

 

I think for educational use, Fossil is probably going to be an excellent choice.

I have a feeling that it has been - and still is - developed and used by primarily academics. smile.png

 

I use fossil on my hobby projects at home and I can attest that it is excellent. It is very easy to deploy and use, and have very few surprising behaviors. I only used it on single person projects though, I don't know how it looks like in day to day use with multiple developers. The repositories being contained in single files is useful for quick backups on for instance google drive.

 

It is also very robust. I actually have installed in as a server on my nas along with a script that automatically pulls and recompile it from the latest trunk version from fossil's official repos a couple times a day, which sounds dumb and suicidal but i've been running this for years and never once pulled a version with any serious bug, and never had to use my backups.




#5221490 GCC -malign-double

Posted by on 05 April 2015 - 11:40 AM

As Bacterius alluded to..this flag can turn out to be very viral.

 

You could say that it is a malign flag.




#5221167 preventing system crash or power outage from wiping savegame: best methods

Posted by on 03 April 2015 - 12:36 PM

 

A bit of explanation is probably called for.

 

The data in question is the bitmap masks for unexplored sections of the local maps in a FPS/RPG. Right now, they are overwritten on save, with no backup. if the power goes out, they get wiped, and the entire 25 square mile area of the game world becomes "unexplored " again.

 

Power outages are a special concern as i'm off grid running off a gen-batt system, and the low voltage alarm on the power inverter is not very loud.  So unexpected power outages are a multiple times a day occurrence here. i suspect laptop users might face similar issues. And since the game will run on laptops (i'm developing it on a laptop board in a mini case) i'd like to make it as robust as possible against power outage.

 

And its not like being on grid is much better - at least around here.  The power goes out in EVERY storm (almost all power lines are above ground in woods in this area). Its quite common for me to be the the only person in the neighborhood with power during bad weather. In fact the power went out two days ago just because of the normal March winds.

 

 

while the game has a built-in cheat to reveal all unexplored areas on the world and local maps, having to use it every few hours because the battery died makes it hard to reproduce the non-cheating player's experience in long term play testing.

 

 

Why load and save the entire map monolithically? Divide it into fixed size chunks and only overwrite those that have been touched since the last save (keep a boolean for each chunk that you set to true whenever you modify that chunk).

 

You could even save them on the fly in a background thread in a temporary file/directory and rename them into an actual game save file(s) when the player wants to save his progress. This way you "save game" function is almost instant (which is nice for the player), and when restarting the game after an unexpected power loss, you can offer the player to restore his "unsaved" progress from the temporary files.

 

Also this is exactly the kind of "mission critical" stuff where i'd definitely trust sqlite over any homegrown solution, by the way.




#5218884 preventing system crash or power outage from wiping savegame: best methods

Posted by on 24 March 2015 - 01:58 PM

 


You can have a look at how sqlite achieves atomic commits using a rollback or a write ahead journal:

 

that was about the only thing i found from googling this

 

http://en.wikipedia.org/wiki/Journaling_file_system

 

it helped refresh my memory about how such things work.  I was into systems programming before I got into game programming, but that was a LONG time ago, back in the DOS 3.0 and DOS 4.0 days.

 

from the wikipedia description, recovery seemed rather non-trivial, especially compared to round robin saves or new save each time.

 

going to SQLite to save what is essentially a header-less 264x264 monochrome bitmap is probably overkill. also, these must page in real time, so performance is "mission critical code". in my mind, "mission critical code" and SQLanything don't belong in the same universe. 

 

 

All "SQLanything" aren't created equal - I suggested using SQLite, not Oracle. It's server-less and writes everything into a single binary file. You could easily store your bitmaps in there as blobs and get the atomic updates, resilience to crashes etc for free. If you use it like just as a key/value store for binary blobs you don't even need it to parse any sql (not that it would matter because parsing a few sql statements when initializing your app wouldn't kill you anyway)

 

As an aside, SQLite and "mission critical" do belong in the same universe, unless you don't consider airliners flight software to be mission critical:

http://sqlite.org/famous.html




#5218622 preventing system crash or power outage from wiping savegame: best methods

Posted by on 23 March 2015 - 03:56 PM

You can have a look at how sqlite achieves atomic commits using a rollback or a write ahead journal:

http://sqlite.org/atomiccommit.html

 

Of course, as said above it relies on the hard disks not lying about flushing their caches onto the physical media. But even in that case it would be a good protection against crashes.

 

You may also consider just using sqlite to store your game save and let it deal with that.




#5218575 Programmatic Pixel Art

Posted by on 23 March 2015 - 01:57 PM

Well the thing is that things like gimp can directly load and save XPM images so you can just edit them like normal images and then just #include them in your code. You still have to decode them into an RGB format before you can use them anyway, so I'm not sure it's really very useful.

 

If you really want to embed images directly into your executable, you might be better off just including images in PNG or JPG in your code using something like bin2c and using stb_image (a full featured image loader that fits entirely in a header file) to decode them.




#5218540 Programmatic Pixel Art

Posted by on 23 March 2015 - 12:42 PM

Has anyone ever tried to do that, you ask? Oh yeah. I can guarantee you that in the medieval ages of computing people were routinely hardcoding graphics directly in their source code like that.

 

You may want to have a look at the XPM format, a text based bitmap format that is also actually valid C code defining palette and pixels as arrays. Some editors even recognize it and can turn into bizarre text editor / image editor hybrids:

Screenshot-xterm-linux.xpm-GVIM.png




#5217043 is it possible to prevent a proggram(specialy a game) to get decompiled

Posted by on 17 March 2015 - 04:37 AM

Doing things client side in a mmo is only "fundamentally wrong" if cheating is your only concern.

More realistically it depends on many factors, including your business model. Having dumb servers and letting clients do most of the work can be pretty justified for a non subscription based game - especially if the gameplay is computationally demanding, for instance because it involves a detailed physic model.

Making the game hard enough to hack can suffice. It's an engineering compromise like everything else.


#5216632 is it possible to prevent a proggram(specialy a game) to get decompiled

Posted by on 15 March 2015 - 09:19 AM

A lot of people see this as an all-or-nothing issue, aka "it's always theoretically possible to defeat a client side protection so there's no use in doing it at all", but it really all depends on the exposure of your game and what type of hackers you end up with.

 

On the game I work on, the only hackers we've had so far have limited abilities: they basically know how to poke half blindly around memory with cheatengine and that's it. So despite a lot of things being done client side and our game using peer to peer networking we've had some good success with relatively simple client-side protection schemes. Those could be defeated by good hackers, but the hackers that have been active in our game so far are mediocre.




#5215628 Questions about GPGPU

Posted by on 10 March 2015 - 05:15 AM

In a similar vein to C++ AMP, there's SYCL, a khronos standard to embed opencl code directly into c++ code.

It's also worth noting that opencl 2.1 adopted a subset of c++14 as a compute kernel language (basically all of c++ except what you'd expect not to be possible on a GPU)




PARTNERS