# nightcracker

Member

18

142 Neutral

• Rank
Member

• Website
1. ## Simple and fast random number generator

I forgot about this topic, and it has turned out to be very interesting! More people that are interested than I thought.   I thought I did it, but I forgot to link the paper of Tyche-i, which can be found here: http://eden.dei.uc.pt/~sneves/pubs/2011-snfa2.pdf
2. ## Simple and fast random number generator

Hey everyone,   I was not impressed with the random quality nor speed nor usability of the default rand() C function. So I took the best non-cryptographic RNG function I know of, and implemented it.   Here it is for your enjoyment! Usage is straightforward, speed varies between 5-12 times as fast than rand(), depending on the situation (inlining, register pressure, etc). Memory usage is low - only 16 bytes per RNG (you usually only need one).   #include <cstdint> #include <ctime> class FastRNG {     /* Implementation of the Tyche-i RNG by Samuel Neves and Filipe Araujo.        Period is expected to be 2^127, with a very good uniform distribution. */ public:     /* If no seed is passed to the constructor it will use the current time        in seconds as the seed. */     FastRNG(uint64_t seed = time(0)) {         a = seed << 32;         b = seed & 0xffffffffu;         c = 2654435769u;         d = 1367130551u;         for (int i = 0; i < 20; ++i) {             randint();         }     }     /* Returns a random integer between 0 and 2^32 - 1, inclusive. */     uint32_t randint() {         b = rotl32(b, 25) ^ c;         d = rotl32(d, 24) ^ a;         c -= d;         a -= b;         b = rotl32(b, 20) ^ c;         d = rotl32(d, 16) ^ a;         c -= d;         a -= b;         return b;     }     /* Returns a number between min and max, inclusive. Small statistical        biases might occur using this method - expected bias is < 2^-32. */     int32_t randrange(int32_t min, int32_t max) {         if (min > max) {             uint32_t t;             t = min;             min = max;             max = t;         }          return min + uint32_t((randint() * uint64_t(max - min + 1)) >> 32);     }     /* Returns a random double between 0.0 and 1.0 inclusive. */     double rand() {         return randint() * (1. / 4294967296.);     } private:     uint32_t a;     uint32_t b;     uint32_t c;     uint32_t d;     static inline uint32_t rotl32(uint32_t x, const int n) {         return (x << n) | (x >> (32 - n));     } };
3. ## Extremely fast sin approximation

That is weird. I profiled with gcc -O3, with MinGW. It might be possible that glibc's sin is incredibly slow compared to VC's, I don't know. Either way, this is how I profiled (it uses stopwatch from https://github.com/n...src/stopwatch.c): #include <stdio.h> #include <math.h> #include "commonc/stopwatch.h" double fast_sin(double x) { int k; double y; double z; z = x; z *= 0.3183098861837907; z += 6755399441055744.0; k = *((int *) &z); z = k; z *= 3.1415926535897932; x -= z; y = x; y *= x; z = 0.0073524681968701; z *= y; z -= 0.1652891139701474; z *= y; z += 0.9996919862959676; x *= z; k &= 1; k += k; z = k; z *= x; x -= z; return x; } int main(int argc, char **argv) { volatile double prevent_opti; int i; double d; cc_stopwatch_t timer; /* cc_sin test */ printf("Testing cc_sin\n"); /* performance check */ { cc_stopwatch_start(&timer); for (i = 0; i < 10000; i++) { for (d = -16*M_PI; d < 16*M_PI; d += 0.1) { prevent_opti = fast_sin(d); } } printf("fast_sin time: %f\n", cc_stopwatch_gettime(&timer)); cc_stopwatch_start(&timer); for (i = 0; i < 10000; i++) { for (d = -16*M_PI; d < 16*M_PI; d += 0.1) { prevent_opti = sin(d); } } printf("sin time: %f\n", cc_stopwatch_gettime(&timer)); } (void) prevent_opti; return 0; } Giving me these results (consequently, not one time): fast_sin time: 147.236370 sin time: 1252.330147 I used GCC 4.6.1, 64 bit Windows 7 SP 1, and 2.2GHz single-core Celeron.

Anyone?
6. ## OpenGL What features should a 2D graphics library have?

I am making a 2D graphics library in Python designed to make 2D easy and fast. Internally it uses OpenGL. The library does cover a bit more then a graphics library, it also includes windowing and sound (and all necessary features to get working, like texture loading). I've got a good beginning working with good performance, and I'd like to expand and refine my feature set. Now I'm wondering, what features should a 2D graphics library have? After some brainstorming I made a little list: Fast sprite class for displaying rotated, scaled, colored and translated textures Sprite batching Drawing geometry: lines, polygons, circles, etc Alpha with blending modes on all of the above Easy texture loading (from file and memory) Texture regions (and texture atlases) Blitting texture(regions) into other textures Particle systems Off-screen rendering surfaces (FBO's?) But I feel I have only scratched the surface of features. What am I missing? One thing you must keep in mind that all of this in Python with C extensions. Any work in the library is fast, any work the user must do is relatively much slower. In addition to that Python calls are quite expensive, so the library largely benefits from batching. (In case anyone cares, the library in question is pygrafix and can be found here: http://github.com/nightcracker/pygrafix)
7. ## Opengl still tries to blur even with GL_NEAREST (GL_TEXTURE_2D)

Nope. After asking this on stackoverflow too (http://stackoverflow.com/questions/8681904/opengl-still-tries-to-blur-even-with-gl-nearest-gl-texture-2d) it seems to be a SOIL bug! Basically, if I pass SOIL_FLAG_POWER_OF_TWO to SOIL_create_OGL_texture it will go wrong. If I don't it won't (and this is only because I apparently have support for NPOT textures).
8. ## OpenGL Opengl still tries to blur even with GL_NEAREST (GL_TEXTURE_2D)

An image says a thousand words, so what about two? I have this map art: In order to actually use this as a map I scale this texture 6 times. This however didn't go as expected: All the OpenGL code is in my homebrew 2D OpenGL rendering library, and since OpenGL is a state machine it is hard to actually document the whole rendering process. But here is +/- what I do (the code is Python): width, height = window.get_size() glViewport(0, 0, width, height) glMatrixMode(GL_PROJECTION) glPushMatrix() glLoadIdentity() glOrtho(0.0, width, height, 0.0, 0.0, 1.0) glMatrixMode(GL_MODELVIEW) glPushMatrix() glLoadIdentity() # displacement trick for exact pixelization glTranslatef(0.375, 0.375, 0.0) glEnable(GL_BLEND) glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA) glEnable(self.texture.target) # GL_TEXTURE_2D glBindTexture(self.texture.target, self.texture.id) glTexParameteri(self.texture.target, GL_TEXTURE_MIN_FILTER, GL_NEAREST) glTexParameteri(self.texture.target, GL_TEXTURE_MAG_FILTER, GL_NEAREST) glPushMatrix() glTranslatef(self.x, self.y, 0.0) # self.x and self.y are two negative integer offsets glScalef(self.scale_x, self.scale_y, 1.0) # scale_x and scale_y are both 6 glBegin(GL_QUADS) glTexCoord2i(0, 0) glVertex2i(0, 0) glTexCoord2i(0, 1) glVertex2i(0, self.texture.height) glTexCoord2i(1, 1) glVertex2i(self.texture.width, self.texture.height) glTexCoord2i(self.texture.width, 0) glVertex2i(self.texture.width, 0) glEnd() glPopMatrix() glDisable(self.texture.target) However, this "blurring" bug doesn't occur when I use GL_TEXTURE_RECTANGLE_ARB. I'd like to also be able to use GL_TEXTURE_2D, so can someone please point out how to stop this from happening?

10. ## Critical library design question

I'm designing and implementing a Python OpenGL toolkit with fast 2D sprite support, very much like pyglet (yet with a completely different approach, for example with a lot of code written in C for speed). But I'm really in the dark about what coordinate system to use. AFAIK most 2D libraries and software uses a top-left origin (with y increasing meaning going DOWN) while OpenGL uses a bottom-left origin by default. Also, AFAIK there are no performance arguments against either solution, since the conversion is trivial. So what is the best origin for a 2D graphics library, bottom-left or top-left?
11. ## Weird bug in pyglet prevents me from using it

I'm sorry, I talked to that friend again and got more information. He has the latest nVidia drivers installed, and opengl works in general. The thing that doesn't work is pyglet.sprite.Sprite. If I blit textures directly it works, but the pyglet's sprite class doesn't work. Any ideas? Should I maybe report this bug to the pyglet devs?
12. ## Weird bug in pyglet prevents me from using it

I am writing a 2d game in Python with Pygame. I only use Pygame for the rendering, and in the way I have written everything so far it is pretty easy to switch renderers, so I made a pyglet prototype and showed it to a friend. Weird thing is, everything worked find on my computer, but he just got a plain black screen. He even got the black screen with the pyglet samples. He even reinstalled pyglet and python, and I even tried shipping an executable built with py2exe, but alas - he still got the black screen. Now this is really demotivating. I would love to use pyglet, because it seems so much nicer, faster and easier to extend with opengl than pygame, but this is really preventing me from switching. I have never had any issues with running pygame everywhere. What could be the cause of this, and should it affect my choice?
13. ## Choosing the right tools

A few other people and I are starting off on a new game. Neither of us has previous non-trivial game development experiences (though extensive game modding experience). The game is a robotics game in the spirit of Robot Arena 2. The goal in the game is to design robots and fight with them against other (AI/multiplayer) robots. The game is in-door (with the exception of maybe 1-2 outdoor arena's). We are going to program the game in C++ with scripting support in either Lua or Python. What libraries/engines can you recommend? I figured we are going to need at least a 3d engine, a physics engine and a sound engine. I found Irrlicht, a seemingly nice 3d engine with a clear C++ syntax. It also has a nice toolchain with irrEdit. Does anyone have an opinion on this, because I saw a lot of (dated) "meh" posts on the internet. I have no idea about what physics engine to use. The main purpose of the goal, fighting other robots, severely relies on physics (e.g., collision detecting, saws, hammers, velocity, weight, crunching). The physics engine must be very good for this. Robot Arena 2 used the Havok engine, which wasn't that great (at least, at that time, it's a game from 2003). Quoting wikipedia: "[font="sans-serif"]One of the main reasons behind the game's relative commercial failure was the relative instability of the Havok physics engine."[/font] [font="sans-serif"] [/font] [font="sans-serif"]Please give some tips/suggestions [/font]
×

## Important Information

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!