Day 06: Testing speed and RebelSDL
Yesterday I spent mostly on checking RebelSDL manual and before that took a little while to find out about Open GL and SDL and came to conclusion that SDL sounded like the better option.
I was very happy to find out that using RebelSDL was much easier than I thought, I was expecting to be having to learn new commandas to use SDL, but actually, it was much much smoother. In best case only difference you need to do in Hollywood to use RebelSDL, is to simply add one line: @Required "RebelSDL"
After that Some of the commands are overtaken by SDL instead of Hollywood.
However, I did need to read the manual since there were some things to take into consideration. Luckily there was no need to learn any commands, but there were some commands, or rather things, I should avoid doing. And also if I was planning to use SDL brushes, I had to use DoubleBuffer. So basically biggest two things were those two lines, to require RebelSDL and to turn on double buffer (which I might had done anyway) after that rest is only about avoiding doing certain things, which I found out in my testing.
So today I took some test to see how many moving things there can be on street.
I started by putting 100 rectangles on screen, and that went completely smoothly, and then i started increasing the amount. To my surprise, even Hollywood itself was well able to handle 1000 filled rectangles on screen smooth. But at 10 000 I noticed Hollywood started becoming bit slow, not bad however, while RebelSDL handled it still well.
I also noticed the draw back of Rebel SDL, when i switched from hollywood to RebelSDL mode, I first forgot to switch the doublebuffer on, and that resulted in boxes drawn somewhat slow, that even drawing 100 boxes was very visible thing without using double buffer and flip. Hollywood without doublebuffer was well fast enough even with 1000 boxes still, that you didnt notice them being drawn.
My estimation is that RebelSDL came perhaps only double+ speed difference, so Hollywood did handle things pretty well, however, it seems like when amount of boxes is increased, SDL gets more edge.
Then I turned to brushes. Even they were 5x5 rectangles, with 1000 brushes, it was already pretty slow. However, 100 brushes while did show slowness compared to boxes, was still quite smooth. Therefore this means that I have chance of executing my plans mostly fully.
That one thing I will forget it different colored balls for people, since for that I would need to use brushes, and unfortunately SDL had no support for drawing circles.
However, Since I am able to move 10 000 rectangles on screen without any problem, Ball humans are not necessity really, since even more fun having more moving objects on screen and also faster to do as i dont need to think how to split the balls, fading the color etc.
On top of that, since my aim is there to be around 200 robots at max (and there is possibility to make that half if i sent them in groups of 5 for example, instead of 10s), it seems RebelSDL can handle that amount of brushes, giving the possibility that instead of rectangles, robots would actually look like robots with some animation.
Anyway, good thing is that drawing is not going to be the problem. However, will the actual moving of 10 000 rectangles become a problem. That might well be. I might have to figure out some ways to reduce their load, like perhaps just move them towards same direction for 10 cycles all the time, and only every 10th cycle do some checking if they reached junction or should change their direction for some other reason. That way I would only need to deal with 1000 people each cycle.
Well, that will be seen when i get map done and put people in there to see how much it slows down if everyones situation is checked every cycle. I am also thinking that perhaps instead of keeping them independent, i could keep them attached to cycles. That way I could for example look it in way of checking each title that robots can be seen from. Then each of these tiles people are woke up to check if they should change their direction away from the robot.
Tomorrow and day after I am plannning to use a lot of time for programming, unless I have boardgame playing or something instead. Today I will already start doing some programming, basically hoping to get the map system at least done.