EVIL_ENT

They are drawn, see this for example:

 

 

and the matching login screen:

 

 

Don't know how it is animated though

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

"ccg games" = "collectible card game games"

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

 

http://ideone.com/5aBW1x

 

#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;
}

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

 

http://www.youtube.com/watch?v=oFV39F_ZJ3s

#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;

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

    glfwGetMousePos(&lx, &ly);

    while (!glfwGetKey(GLFW_KEY_ESC)){
        glClear(GL_COLOR_BUFFER_BIT);

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

        /* 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;
        glBegin(GL_LINES);
        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);
        }
        glEnd();

        glfwSwapBuffers();
    }
    glfwTerminate();
    return 0;
}

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

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.

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

edit:
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
http://en.wikipedia....pping_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)

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

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

I couldn't find any setup for your depth buffer.
http://www.opengl.or...depthbuffer.htm
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.