Jump to content

  • Log In with Google      Sign In   
  • Create Account

Interested in a FREE copy of HTML5 game maker Construct 2?

We'll be giving away three Personal Edition licences in next Tuesday's GDNet Direct email newsletter!

Sign up from the right-hand sidebar on our homepage and read Tuesday's newsletter for details!

We're also offering banner ads on our site from just $5! 1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


Member Since 14 Aug 2010
Offline Last Active Sep 04 2013 01:10 PM

#5081540 GLSurfaceView lag/delay

Posted by EVIL_ENT on 29 July 2013 - 02:02 PM

I noticed that even the default CyanogenMod UI has some delay, so it either is a hardware issue or OS issue.

Further I found two more threads which appear to be about the same problem, no solution through:



It is mentioned that there should be less lag on HTC devices, and I read somewhere else that iphones should have less lag, too.



Seems like not even the developers are sure what the reason is.


Anyway, unless we hack into android we can't change it.

#5081283 GLSurfaceView lag/delay

Posted by EVIL_ENT on 28 July 2013 - 03:20 PM

I noticed the same thing (input lag when using GLSurfaceView) on a samsung galaxy s2 with android 2.3.3 or something around that weird version number.

If you use the Canvas element for painting instead you have less input lag, so it might be possible that the other apps you checked which didn't have input lag were not using OpenGL.

I suspect it's either double buffering or maybe I caught the touch events at the wrong place.

Anyway, I still have to check if this is still the case on non-stock android roms.

#5069109 How to interct with the five million dots

Posted by EVIL_ENT on 12 June 2013 - 06:18 AM

If dots can't overlap and have discrete positions your editor could be a paint program. Store pixels (aka dots) in a big array (or hashmap if they are sparse).

Otherwise a quadtree is a good idea as 0r0d pointed out.

If you have a uniform distribution of dots a grid with a fixed size might be faster and easier to implement though.


As you can see it's possible to get down from O(n) to O(log(n)) or even O(1) based on your constraints, so it is essential to mention as much as possible.

#5063030 Separation of concerns in game architecture

Posted by EVIL_ENT on 19 May 2013 - 11:10 AM

If tile and sprite should be one thing it might become bothersome to animate a SpriteTile to move from one location to another smoothly (in case this would ever happen).

Anyway, this are very specific implementation details which would require a more specific description of the game.

#5062019 How do I replicate the league of legends login screen?

Posted by EVIL_ENT on 15 May 2013 - 05:53 AM

They are drawn, see this for example:



and the matching login screen:



Don't know how it is animated though

#5061307 Beginner wanting to learn how to program CCG

Posted by EVIL_ENT on 12 May 2013 - 11:49 AM

I'll save a few people the need to google:

"ccg games" = "collectible card game games"

#5055680 Sorted particles and SIMD

Posted by EVIL_ENT on 22 April 2013 - 02:26 AM

my code appears to be roughly twice as fast as std::sort for big n in my probably wrong tests:




#include <stdlib.h>
#include <stdint.h>

#include <time.h>
#include <assert.h>

#include <algorithm>
#include <iostream>

void radix_sort(uint32_t *in, uint32_t *out, int shift, int n){
    int index[256] = {};
    for (int i=0; i<n; i++) index[(in[i]>>shift)&0xFF]++;
    for (int i=0, sum=0; i<256; i++) sum += index[i], index[i] = sum - index[i];
    for (int i=0; i<n; i++) out[index[(in[i]>>shift)&0xFF]++] = in[i];
void check(int n){
    uint32_t *data = new uint32_t[n];
    uint32_t *temp = new uint32_t[n];
    uint32_t *same = new uint32_t[n];
    for (int i=0; i<n; i++) same[i] = data[i] = (rand()<<16)|rand();// Note: rand() might not produce enough randomness

    clock_t t_radix = clock();

    radix_sort(data, temp,  0, n);
    radix_sort(temp, data,  8, n);
    radix_sort(data, temp, 16, n);
    radix_sort(temp, data, 24, n);

    t_radix = clock() - t_radix;

    clock_t t_sort = clock();

    std::sort(same, same+n);

    t_sort = clock() - t_sort;

    std::cout << "n: " << n << std::endl;
    std::cout << "radix_sort: " << t_radix << std::endl;
    std::cout << "  std:sort: " << t_sort  << std::endl;
    std::cout << std::endl;

    for (int i=0; i<n; i++) assert(same[i] == data[i]);

    delete[] data;
    delete[] temp;
    delete[] same;

int main(){
    for (int i=0; i<30; i++) check(1<<i);
    return 0;

#5048319 Drawing infinite grid

Posted by EVIL_ENT on 30 March 2013 - 08:41 AM

You don't have to draw an infinite grid to make it look like one:


#include <GL/glfw.h>

int main(){
    int x, y, nx, ny, mx, my, lx, ly;
    int dx = 0;
    int dy = 0;
    int w = 512;
    int h = 512;
    int cell_w = 32;
    int cell_h = 32;

    glfwOpenWindow(w, h, 8, 8, 8, 8, 0, 0, GLFW_WINDOW);

    glfwGetMousePos(&lx, &ly);

    while (!glfwGetKey(GLFW_KEY_ESC)){

        /* Make OpenGL cover full window size */
        glfwGetWindowSize(&w, &h);
        glViewport(0, 0, w, h);
        glOrtho(0, w, h, 0, -1, 1);

        /* Handle mouse input */
        glfwGetMousePos(&mx, &my);
        if (glfwGetMouseButton(GLFW_MOUSE_BUTTON_LEFT)){
            /* Offset the grid by the distance the mouse moved */
            dx += mx - lx;
            dy += my - ly;
            /* Use the %-operator to jump back */
            dx %= cell_w;
            dy %= cell_h;

            float r = 10.0f;
            glRectf(mx-r, my-r, mx+r, my+r);
        lx = mx;
        ly = my;

        glTranslatef(dx, dy, 0.0f);

        /* Draw a grid which is a little bigger than the screen */
        nx = w/cell_w + 2;
        ny = h/cell_h + 2;
        for (x=0; x<nx; x++){
            glVertex2f(x*cell_w,  -cell_h);
            glVertex2f(x*cell_w, h+cell_h);
        for (y=0; y<ny; y++){
            glVertex2f( -cell_w, y*cell_h);
            glVertex2f(w+cell_w, y*cell_h);

    return 0;

This is deprecated OpenGL. With a fragment shader this would be much easier (but much harder to setup).

#5013614 Feasibility of writing android apps purely through the NDK

Posted by EVIL_ENT on 23 December 2012 - 02:53 AM

Also I heard that the speed difference between NDK and Java code really isn't very noticeable (if at all) because the Java code gets recompiled to native instructions anyway (it isn't interpreted), so I'm not sure if that could really be considered an advantage. I suppose NDK still wins if you really don't like Java, though =P


I wrote a very simple space shooter and got performance problems as soon as there were like 30 ships moving around at once, than I wrote the same again in native code and suddenly could manage 10 times more ships without doing any structural changes to the code.

That was on api 8 though and I have heared that dalvik became faster since then and that FloatBuffers have been fixed (there was a problem that wrapping a floatbuffer around a float array would call floatBuffer.put on every element instead of doing something smart).

There were also some functions missing so one could not write efficient code and had to use JNI wrappers anyway.


In my opinion the google guys are a little too fond of their dalvik vm. In practice native code is a lot faster and should be prefered if there are even remotely computationally expensive tasks to do.

Also will give you more battery life.


I have written a windows/linux framework for developing and debugging, so I don't have to mess with eclipse/android can just copy the files for final release.

#4963919 Voxel Based Water

Posted by EVIL_ENT on 28 July 2012 - 05:55 AM

A search for "tall cell grid" might turn up helpful results (there are a few papers about it)
You could even do real water simulations with it, e.g. this

#4913086 Polygon Clipping

Posted by EVIL_ENT on 14 February 2012 - 01:27 PM

the jittering algorithm appears to fail in 0.1% of all cases
I'll try to find a better way

I implemented this polygon clipping algorithm

here you can see it working

solving degenerate cases is very troublesome though
at first I tried to handle every degenerate case properly but it seems to be very hard to impossible
since I don't need 1000% accuracy (I am fine with up to 0.5 pixel of jittering) I decided to randomly move polygon points until all degenerate cases are gone but I must have overlooked something

I am trying to get this to work since months so I decided to ask for help

the algorithm is supposed to subtract a polygon from another polygon and returns a list of polygons as a result of this subtraction
how it works:
1. create linked lists of vertices from both polygons
2. randomly move vertices until they are not on top of any lines
3. calculate all intersection points twice (once for each polygon) and connect them
4. insert intersection points into linked list of vertices
5. start at any intersection point and move through the linked list, swap list if another intersection point is reached

is there any easier way to deal with degenerate cases?

sidenote: I also tried java topology suite but for some reason it is a few tenthousand times slower (no exaggeration)

#4897949 Did the first pong game use continuous collision detection?

Posted by EVIL_ENT on 29 December 2011 - 04:32 PM

actually I don't know how they did it but something like this should work:

//ball is an object with velocity (vx and vy) and a position (x and y)

while (gameIsRunning){
	ball.x += ball.vx
	ball.y += ball.vy
	if (ball.x < leftPaddel.x || ball.x > rightPaddel.x){
	    //move ball back so it won't penetrate the paddels
		ball.x -= ball.vx
		ball.y -= ball.vy
	    //"collision response code"
	    ball.vx = - ball.vx

this will look like it froze for one frame every time it hits a paddel but nobody will notice

#4852926 [java] NEEDED: A kick-ass *junior* Java developer who wants to live in Barcel...

Posted by EVIL_ENT on 23 August 2011 - 02:01 PM

You want the worlds best Java programmer for less than 3 Euros per hour? :blink:

#4833326 Quad appearing infront of other Quads problem

Posted by EVIL_ENT on 10 July 2011 - 08:07 AM

I couldn't find any setup for your depth buffer.
If you don't have any depth testing opengl will display what you have drawn last on top of everything.
Same what happens when drawing in real world.

You could also sort your objects yourself so you begin drawing with the objects which are far away.
But if you have objects which are intersecting each other that won't work.