Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 19 May 2007
Offline Last Active Sep 12 2016 07:29 AM

#5307406 Decent vector library for C?

Posted by on 23 August 2016 - 08:52 AM

Depending on what you want out of it, there are a number of possibilities here as well:


#5216309 How should i manage intro animation

Posted by on 13 March 2015 - 12:13 PM

Based on the example you showed, you will want to make an animated movie, and simply play the movie back using SFML.

As for how to make the movie itself, that is not a programming issue. You'll use animation software for that.


There are other ways to make animated intro sequences, but you should start here for now.

#5192902 DigitalRune Engine Opinions

Posted by on 14 November 2014 - 03:54 PM

If this is for a new game project, what are your criteria for choosing this instead of something else out there?

#5189768 Current state of custom and commercial game engines as of 2014

Posted by on 28 October 2014 - 01:44 PM

And yet another topic is the relative lack of low level and techniques/new tech tutorials or articles, as they're not so many as they were years ago. This is also a byproduct of the game engine/tech developers, due to this new segregation of the market.

Must disagree with that. If anything, there are more low level techniques being shared than ever, IMO.


Anyway, if tool dev is your thing, I guess you'll have to come up with something that hasn't been done yet, or at least something you could do better. Without knowing your experience, it sure would be nice to have a good dynamic music creation tool available, for instance. Point being, there are tons of niches that haven't been filled yet...

#5189673 synthetic instruments tutorials?

Posted by on 28 October 2014 - 06:43 AM

The simplest type of synthesis is subtractive synthesis. There are others, but you should definitely start there (don't be fooled - subtractive synthesis will give a huge variety of sounds).


That link actually provides a fantastic yet simple explanation, so I would probably fall short in trying to go any further or summarize here. Cool project - have fun!

#5189468 [Fixed]Image parsing : Read all file or x bytes at a time ?

Posted by on 27 October 2014 - 01:22 PM

It was the debug, I set the configuration to release and suddenly it worked in less than a second smile.png


I guess I should read up on debug time sanity checks, I don't really know much about those.


For instance - every time you have something like this 


bufferRestOfFile[index + 2]


the code for std::vector in a debug build will typically check that the index given in the [] operator is a valid index into your vector. If it is not, it will assert or throw an exception, depending on implementation.


In release builds, this is generally not done, but in debug builds it is normal.


Side note: There are usually flags you can set at compile time to configure the depth of debugging done, depending on how much you need checked vs how much speed matters in your debug build.


Side side note: Some people will actually enable these debugging features in release builds for security purposes (and do other things such as reference the raw data pointer when this is a speed bottleneck and they have verified the safety of what they are about to do)

#5188379 Reading PNG format (deflate compression)

Posted by on 21 October 2014 - 02:07 PM

In other words, if you expect your final image data to start with the byte '255', and you have a scanline filter of 1 (sub), then your next byte should be a 1. (0 minus 1 -> modulo 256 -> 255)


Not quite.


For the first byte, you can just write the raw value. The equation is (curr - prev), and x < 0 is defined as 0. So filtering with the PNG subtraction filter would give 255 - 0, mod 256, which is still 255. So byte 1 would be "1" for sub filter, and byte 2 would be "255".

#5188312 Reading PNG format (deflate compression)

Posted by on 21 October 2014 - 08:35 AM

By the way Lehm2000, the first byte of data on each line will be the filter type if you didn't figure that out by now. So, the "1" indicates a subtraction filter. I suspect your deflate decoding is okay so far.

#5188309 Reading PNG format (deflate compression)

Posted by on 21 October 2014 - 08:27 AM

Lehm2000 has already begun to understand deflate. If they want to explore it, and this is all for learning, just let them. It is what is currently interesting to them, and it's a good experience.


[edit] That isn't to anyone in particular - there are just multiple posts saying in one way or another to avoid this path, instead of helping with the actual question about deflate. However, this poster has demonstrated a certain amount of understanding with deflate, and they just need a little nudge to continue on.

#5188293 Reading PNG format (deflate compression)

Posted by on 21 October 2014 - 06:07 AM

I've done this and it's a lot of fun :) Learning to implement specs like this can be a challenge - especially your first few.


Why don't you take your simple png file, and run it through something without restrictions such as stb_image and just trace what happens? Adjust your code according to what you discover :) Also don't forget that there is filtering on the png image which may give you different zlib output data - although it shouldn't touch the first pixel.

#5187643 DLL-Based Plugins

Posted by on 17 October 2014 - 08:20 AM

Having worked on a few plugin systems...


For a good example of a working, implemented plugin system, the Doom3 source code actually comes to mind. Essentially, the engine is exposed by the application, and the game is in the DLL. Some highlights:

  1. The exposed interface is in C (though internals can use C++ or anything else). Functions are stored in structs.
  2. They "handshake", which trades the engine (in your case - editor) API for the DLL to use, with the DLL's exposed functions for the engine/editor to use


  1. As for as ownership goes - if you normally have good practices in this area, it works the same with DLLs. Whoever made it (the object) is responsible for it.
  2. Consider how you will handle API changes whether from the editor side or the plugin side. If you "trade" APIs with each collected in a C struct, it may be easier to manage
  3. How will you store this information in your editor file format, and what will you do if a required plugin isn't on the system?
  4. All the previous posts apply, of course. Watch non-trivial objects, packing, alignment requirements, etc. If an object changes even by a couple bytes, or a couple members get switched around, it either needs to be versioned, or any plugin using an older editor SDK needs to be detected as deprecated and unusable. Ever written a BMP file loader? There a few different header versions. The idea is similar.

Generally, there are ways to ensure that (most) compiler flags don't muddle up your interface. If this is something you're interested in, the experience of it will teach you more than this whole thread though!

#5186894 Choosing a graphic library

Posted by on 14 October 2014 - 06:23 AM

http://urho3d.github.io/ is another possibility. It integrates a lot of the different parts together (sound, physics, networking, 3d, etc), but you could certainly take the graphics capabilities and glue your own systems together with it. That would of course re-invent what is already there in this package, but it does meet your requirements, I believe.

#5186221 Passing A std::vector as a Pointer to a Function

Posted by on 10 October 2014 - 12:22 PM

The previous answers are the correct ones. However,


data[0][elementinvector].doobjfunction(); ///Is this valid to use.


is valid and would work, to answer your question. It would be a really poor idea though, and would confuse anyone that ever looked at your code, because it misleads you to believe there is potential for multiple "std::vector<obj>"s in "data".

#5185847 I need to fill about 6MB of memory per frame, fast algor needed

Posted by on 08 October 2014 - 03:04 PM



Try to find a way to keep each memory access as close to the previous memory access for best performance.


I seems very interesting. Could you elaborate a bit on that?





It's a general statement.


1) Storing bits instead of bytes (if all you need is 1s and 0s) helps because all your data is much, much closer together.


2) If you calculate only 1 step and reuse the other 254 (or if you can do that even if you aren't already), you, again, can touch only the memory in that step. Otherwise, do you calculate all steps for an agent, then move to the next agent? If so, store all steps together in memory. (agent1_step1, agent1_step2, ..., agent1_step255, agent2_step1, agent2_step2, ...) Or... do you loop through all agents on step 1, then all agents on step 2, etc.? In that case, your memory should be structured the same (agent1_step1, agent2_step1, ..., agent20_step1, agent1_step2, agent2_step2, ...)


3) And so on, and so on.... the point is that even if you access memory randomly, there is some overall pattern you can take advantage of so that they are still locally similar. Even better is if you can process pixels in your agents sequentially... but it's still not totally clear what you're doing and how you're doing it so that's about all I can tell you. Maybe you can get even trickier and trickier (working on multiple bits at a time, multithreading, etc) but who knows. Start with access patterns as mentioned above...

#5185842 I need to fill about 6MB of memory per frame, fast algor needed

Posted by on 08 October 2014 - 02:39 PM




I need to fill a vector of 6MB every frame, is there a fast algorithm to do so?

You may assume this is a flat type configuration, with a boolean in a std::vector,

one followed by another. I find that if I use a bitset<8> instead I can reduce the size of memory

to about 400KB, so what is the best way in your opinion?




First of all, if you're storing bits, not bytes, the memory you need is 30x30x255x20 / 8. Which should give you ~570kb.


Second of all, you can fill that very fast, each frame. It's not really that much data. Using bitset works fine, though you may get more speed doing it by hand. Of course this depends on your frame-rate but it's still not that bad - though at 50FPS+ you are starting to take a hit on your available memory bandwidth (depending on what else you are doing in your software this could be fine or could be an issue)


Third - general memory rules apply. If you can write to memory in order rather than randomly, or if you can identify a pattern (which you can then re-organize your data), that will help. Try to find a way to keep each memory access as close to the previous memory access for best performance. If you can avoid some calculations (do you need to calculate all 255 steps each frame?) as Servant mentioned, that is even better.