LöveJIT + 0.8.0 + windows?

[utunnels]

This was built a week or so ago: http://dl.dropbox.com/u/4214717/LoveJIT-0.8.0-win32.zip

I'm sorry to hijack this thread. But it seems this build script runs slower than 0.7.2 on my PC. I mean, I used to have some nasty loops that checks hundreds to thousands of pixels per loop (I set fps to around 60). The game ran as smooth as silk in 0.7.2 but lagged a lot in 0.8.0.

Also I notice lua function print no long prints anything to the console.

BTW, the new utf-8 string support is great.

[slime]

What's the code exactly? Lots of things have changed internally with 0.8.0, but I'm not aware of anything that would cause a slowdown like that.
The console issue in windows has to do with linking Lua dynamically rather than statically. It might be fixed by linking dynamically with the visual studio runtimes, and including them with LÖVE. I'll see if I can get that working soon.

[utunnels]

I wonder if dynamic linking can cause some sort of slowdown.

The code was something like:

Code: Select all

blahblah...

for i=0,somewidth-1 do
    for j=0,someheight-1 do
        local r,g,b,a=someimage:getPixel(i,j)
        if a~=0 then somecounter=somecounter+1 end
    end
end

return somecounter

I know I need to do some optimization, but I still worry about the performance. Could the function getPixel be slower so I need to create my own boolean array or there's some other reason, I'm not sure.

[slime]

I don't think the getPixel code is slower in 0.8.0, however it's very slow in general and definitely shouldn't be used en masse every frame.

[utunnels]

I see, thank you.
I guess unless there's a build in function checks pixel overlapping, I shouldn't do such thing with lua loops.

[Boolsheet]

If I remember correctly getPixel and setPixel are thread-safe in 0.8.0. It's slower because it has to lock for the synchronization of threads.

[slime]

Ah, that's a little unfortunate that it noticeably slows it down.

[utunnels]

Well, I tried the same game a minute ago and it ran without lag this time.
It used to be slow when I posted in this thread last time. I even tried pre-loaded boolean arrays instead of getPixel but it only made the game slower so I gave up.

During this time I downloaded the source code, learned some basis such as what is luaJIT and such. Then I realized it was not possible to have table operation slower in luaJIT. I wrote some test code and found the JIT version is actually much faster. After that I loaded the game and found the lag had already gone.

I have nothing to say, perhaps my computer just had a fever.

[miko]

Well, I think the issues are my ideas for the game more than the code itself The game is running with 20.000+ entities which are making decisions (hello AI!) depending on the state of their closer allies, shooting (hello collision detection!), navigating the map (hello simple pathfinding!) and are shaded using a simplified FOV (hello... you, intensive calculation!). So, I'm not really surprised it came this way. Of course, I will keep on optimizing the code, I think it's time to start using some sort of spatial hash to try improving it, and perhaps the pathfinding algorithm can be simplified, but one thing is sure: this little monster needs to compute a lot of things.

Seems like a lot of calculations, really. Did you consider using love.thread for offloading some of it? Anyways, good luck with your project! I would surely love to look at it once you release it.

[kikito]

Basically, if the entity has to be drawn (culling is in place), everything has to be calculated (except pathfinding, which is only calculated when the path has to be reevaluated -which depends on the movement of the other entities...-). When they are not visible they don't "move" to their destination, they just calculate the point and "jump". Also, they don't think too much. And if they are rendered they are shaded. The point is, it's very common to see a few thousand of them at the same time on screen.

The AI of your ships is supposed to simulate alive pilots, right? Most humans have a reaction time of 0.5 seconds or so. If you are calculating the visible ship AI routines every frame, your pilots have a ~0.01s reaction time. That not only is cpu-intensive, that's also a bit unrealistic .

The decision-making & map navigation, for example, are perfect candidates for re-calculating every 0.5 seconds or so.

A quick implementation would be: have an internal property called "timeSinceLastAI" internal value per ship. On each update, increment it with dt. If timeSinceLastAI >= threshold, perform full AI and reset timeSinceLastAI to 0. Otherwise, do what was decided recently (continue in the same course, acceleration, firing to the same place, etc).

This has some impact (your AI has to plan the moves for the next half-a-second instead of just the current frame, so you may have to store that information so it is available during the "no AI" time) but your cpu consumption should be smaller, especially if you AI is expensive. Of course, you have to make sure that all ships don't calculate their AI exactly on the same frame, so the AI calculation is "distributed" (maybe adding a tiny random bit to "threshold" when creating a new ship).

In addition to CPU and realism, this gives you more possibilities in the gameplay; it gives you a rough "pilot difficulty": good pilots may have 0.5 in their threshold while bad ones, or ships on the verge of collapse, will have 1.0, for example. You can have a "mental distorsion weapon" that temporarily increases the AI threshold in the target ship. And you might have resistances to mental rays depending on the race, or mental shields in ships.