When I run vcmi, the intro screen is eating about 80% cpu, while doing absolutely nothing.
I’ve made that small patch to solve that problem by not redrwing the screen when no event occurred, but I wonder if it’s the right thing to do.
I’ve also looked at why the game itself eats 100% cpu, and it’s the same problem. I made some changes to CPlayerInterface::yourTurn to not redraw all the time, but I lose the animations.
I don’t know if the redrawing issue is related to the feeling that the game is overall quite slow. vcmi_speedup1.zip (606 Bytes)
As comparison, here’s how much VCMI eats on WinXP platform on a system with the specs in my sig, in case it’s relevant for the devs (otherwise please ignore this post :p):
[ul]a- Starting the client: ~40% for less then a second, then stabilizing at 7-8% for the Main Menu
-a Loading a saved game (map size M, 90% explored, 4 heroes, 1024x768): ~35% for a second, then stabilizing at 16~20% in the Adventure Map interface
a- Opening another window on top of the VCMI Client with Adv.Map active: drop to 7-10%
-a Opening Hero screen: small increase to ~22%
-a Opening Town screen: short boost to 25-30%, then dropping to 15% (bit less then Adv.Map)
-a Opening Tavern screen: drop to 11-13% (was interesting to notice that opening window in window leads to drops in CPU usage)
-a Opening another window on top of the VCMI Client with the Tavern window active (Town screen AND Adv.Map still visible in the background on 1024x768) let surprisingly to a drop of the CPU usage to 0%
-a Town screen after hiring hero: 22-25%
-a Hero moving on Adv.Map: ~25%
-a Battle: static ~25%; creatures moving/attacking ~35%
-a Battlefield Casualties screen: 45-50%
-a Opening a window on top of the VCMI Client with Battlefield Casualties screen still open: client still eats 25-35% of CPU[/ul]
Those were the most relevant values I noticed of what I tested. Note that restarting the map from scratch (1 hero, unexplored) or even starting maps of other sizes (S to XL) did not have noticeable impact on the percents given above. So it seems that the map size, revealed area or number of heroes don’t really impact the performance.
It could be the right thing in preGame, but certainly not in the rest of the game.
Actually it needs to readraw almost all the time. There is a possible speedup while moving hero in smooth mode - screen could be blited by 1 pixel in right direction without rerendering everything. But I don’t think it’s good thing to do as we are going to reimplement graphic rendering code in OpenGL during this summer.
So it would be hard whithout anything on top of opengl…
if you mix 3 libs (allegro allegrogl opengl) you could work using opengl, and having nice programming interface due to allegro, which is technically wraper for hard-to-use graphic libraries
in allegro you have tiny smart set of commands (functions), so you use the always the same function for blitting and (BITMAP*) bitmaps so implementation is subject of the inner of allegro
allegro has the system of semi-drivers so you could choose the method of acceleration (DX, gdi, no-acccel) on the start and implementation is the subject of inner working of allegro, allegrogl simply adds semi-driver for opengl library, so it could have good acceleration not only on windows
allegro isn’t moveable, but has same-working implementations for almost each operating system and for most known compilers
and the pointer type (BITMAP*) can inner have many implementations of bitmap even in one compiled implementation of programs ie. you could have fastened bitmaps, normal bitmaps or system bitmaps each availible due to (BITMAP*) pointer
for image loading it can have further addons to allow load other types of bitmaps than default
and, what’s funny, it could work for C without '+'ses too
allegrogl works invisible, only you tell at initialization that you use allegrogl instead of ie. directx_windowed
simplicity: it chooses the most good choice at your current choosen mode ie. if you have plain graphic-based program with no-accel then if you change to ie. directx_fullscreen, you need no more changes over the one - mode, and it boost speed moderately 1.5x to 4x (depends how often you use commands able to boost)
but if simple is to simple you can use few specialised functions which works with the same (BITMAP*) ie. change pallette, color resolution, put up pixel, while each (BITMAP*) you blit in … blit() function (with parameters)
it support RLE sprites, compiled sprites, plain allegro bitmaps, system bitmaps (ie Windows’s others windows)
C vs C++
it’s written in the way if author feel to C++ come:
it’s based on struct pointers (similar to class objects)
it has simple UI mode (optional) when you work on (DIALOG*) table (terminated with object starting of NULL pointer, so size dont affect) which every item has pointer to the function which has type of event as a parameter - yes event based before c++ born
and from giving it rest in C form you get all childs public and no baloon-buffed classes but function working (mostly with first parameter (BITMAP*)), only on this what is really needed
so you dont feel of lacking ‘+’
PS: by ‘moveable’ i mean polish ‘przenośne’ but maybe i translate it wrong
so i meanby ‘not moveable but same-implemented’ there’s no universal code for all platforms but there’s a version diffrent for each well known enviroment (works similar as BOOST’s part where code is script generated, or simillairy to boost you got ‘extracted’ version for one-option)
PS2: i write extracted not meaning exctract from archive but succes choice&mix&mount of parts
EDIT: @not popular allegrogl
man which made allegrogl has known that only OpenGL support is missing from main features
If it’s done by only one man, I doubt that it can be used for anything. After experiencing problems with SDL and seeing its slow developement I want a library with large community behind it. After reading your posts Allegro + allegrogl seems to be only a bit better than SDL + glSDL. Furthermore, SDL is enough for us for event handling - I don’t think we could use Allegro & SDL simultaneously (because nobody would like to rewrite well working event handling).
I don’t know many about makers of allegrogl, but i think a man wise in opengl could in one-two months write it because the most important in allegro is simplicity
he/they don’t have to rewrite many of allegro but only write the semi-driver which is an interface betwen inner allegro and outer graphics libraries
about event handling i have in mind GUI events such as mouseover, click doubleclick etc
i believe doing gui in allegro is much simplier than in SDL, but i understand your point that allegro+allegrogl is somewhat similair to sdl+glsdl, so you doubt if it is worthable to port in to allegro
I think you can leave ~96% of code as is due porting and anything able in sdl is able in allegro and much more… I believe even that rewriting pregame from scratch in allegro by one person eats much less than one day (read “a few hours or even less than one hour”)
so porting all of it to allegro will be about a week i think, but I understand if you don’t want to use whole week for such an reorganisation, but if done properly it may ease further extending of the project
Apparently SDL does a shadow scaling if the surfaces given are not the same depth of that of the screen. And that’s very expensive. It’s transparent on windows because it’s using the hardware to do the job, but on linux there’s no acceleration for that.
After changing the depth from 24 to 32 (which is my resolution depth), the pregame and the adventure map became much more responsive, with number still higher than Zamolxis’, with a nearly identical hardware. However the combat screen is broken (as the comment in setting.txt suggested). But now that the reason is known, the fix shouldn’t be too hard.
Moving to opengl should solve the problem, but will make the game unplayable for people without opengl drivers.
if you choose allegro then, you could do that if player is using opengl or DX is chooseable towards setttings file, or chosen at program start, so with almost no work it’s able to work with diffrent graphic liblaries
(so maybe it’s a reason to switch to allegro as acces to graphics library is chosen at runtime)
Is there anybody who doesn’t have openGL drivers? I think everybody has them or can easily install them.
Just one week? So it must be extremely easy since we need many different parts of SDL in a lot of places… What about blitting 8bpp bitmaps with alpha to 24 bpp bitmaps? Framerate managers? Key events, mouse events (moving & clicking), sound support? What about rendering creatures in battlefield? The last one is exceptionally hard - we can choose either:
using 32bpp surfaces to store them (it needs gigabytes of memory - I’ve calculated it some time ago)
using 8 bpp surfaces with alpha support (just 1/4 of those gigabytes - and SDL does not support such surfaces)
direct rendering of creatures by pixel manipulation - very costly for hardware surfaces if not done on graphic card.
Currently we are using the third method - it’s acceptable for surfaces stored in RAM. How could we do this in Allegro + AllegroGL?
direct pixel manipulation works in allegro due to publicity of all elements of bitmap
but better will be caching ie. cache for every creature and use only those used in battle and rest unloaded - it would be fine because allegro has its own filemanager (easy to write compresed datafiles)
blitting textures with differ collor-bitrate would be fine just blit(), transparency supported (for one user chosen color which may differ on each bitmap) just give it know it uses transparency during blitting
framerate menagers could be easily done due to allegro timer (timer can do a function marked by some allegro specyfic macro in custom ticks of miliseconds) and even you could force to dont refresh specific parts of gui just write custom gui function (which may of course call default gui functions when needed to mirror functionality)
key events and mouse events are easily done if using allegro gui mode
sound is one of easiest in allegro
only base gui functions make dusty interface, but we can againsts use replacement set from agup which accepts skins (AGUP - allegro gui un-uglification project) so only add agup word to basic gui function names
even i think gui done in plain table with void pointers few integers and function pointer is easier to use than heavily-builded class-based guis from late c++ (like borland gui for c++)
even we have an addon to allegro to have c++ console with c++ i/o on allegro bitmap
in separate extension library
funny I think you can do in allegro is bind your own class to one of gui element void* pointers and one friend function for the function pointer so you can use even gui classes
in example i could do a primitive-based snake in less than 20-minutes (allegro has functions to draw few types of primitives on top of bitmap objects)
simple tile based game with no scrolling - about 20minutes and a few pages of code
allegro is EXTREMELY EASY in use
if we have problems with porting we could change for-sdl functions to some type of handlers and use them in allegro gui functions, even we can do batch edit of code if you don’t fear to. most easy if you use typedefs so you could change the much less function giving them compatibility with older type stored in those typedef
on hot work it would be about a week, with “more lazy” coders it may took a month for one person, but if we share parts of code for modify to diffrent coders it could be done in a week or less for the community of “more lazy” coders
*“more lazy” is just an expression which isn’t planned to be offensive
EDIT: about framerate it’s gui dependent and it rules to don’t refresh when not needed, if needed just return appropariate signal and you make appropariate gui parts to know that needs refreshing (easiest way is refresh-me or refresh-all), and its good news because we have an incredibly much control on gui
In the linux world, it’s less clear. Opengl support is usually provided by closed drivers from ATI or NVidia. If you don’t have one of these drivers (because they don’t exist or because you don’t like proprietary drivers) then a software emulation is used. Then emulation can only do a few frames per seconds (ie something like 5). I was in that case until a few months ago when I upgraded my hardware.
somewhat yes, I seem to be Alegro fanboy
but when I meet this i was brilianted whith ease of use.
I don’t know too much about sdl, but i couldn’t imagine easiest to work library than alegro, moreover it has whole set of i/o functions (mouse, keyboard, joystic, file, graphics, sound and probably more) in one integrated library, and if there’s anything it cant do, you easily find a plugin
allegro is called game library not whit hout a reason, it has all function needed to do a game, and it works very simple for coder, and i found on allegro the functionalities which i though impossible looking at other libraries
I’m discovering more and more fun&functionality at allegro and i see no drawbacks… hmm compressed allegro data files are uncompatible with other i/o library bu you can work on simple not compressed files and thats ok
look at allegro.cc there you find many projects with allegro, and a group of coders (maybe somebody more experienced could find a drawback )
allegro seems to be ideal for any games in 2d and somewhat less ideal for games in 3d (but has 3d mode support)
So I have a new reason to don’t like Linux :). Heroes III, released 10 years ago, requires DirectX acceleration. And now it occures that Linux developers are not able to provide any hardware acceleration for every significant distribution… it’s piteous.
Current performance of VCMI is quite low on higher resolutions, even on a good hardware. I think we cannot improve SDL version significantly so we consider using GPU instead of CPU for rendering.
Linux GPU driver stack is in worse condition then Windows but it’s not as bad as Ubuntux paints it to be. You also misread his comment as you say:
which is just false and may seem you assume that out of personal hate for anything that’s not Microsoft … As you state it’s another reason for you to:
but honestly whether you like this OS or not you should still try to at least be fair and not assume things and spread FUD out of nothing as you did it in this case.
That being said Ubuntux is also wrong even though he is a Linux user :), because X.org mesa is not just a software emulation … It has hardware acceleration for quite a lot of chips. What chip did you have ubuntux ?
Let me now explain what the situation is :
For most it’s also not a problem that devs do not care, but for years they had to reverse enginer GPUs, because hardware manufactures did not provide the specs… As a programer you can imagine how hard it is to write a driver for a chip you know nothing about… BTW it’s not that Microsoft writes 3d drivers for their OS isn’t it? It’s Nvidia Ati or Intel that provide the drivers …
Since about 2 years time situation improved greatly with both Intel and Nvidia providing documentation and funding the development .The situation right now is :
Nvidia - good closed source driver with support for OpenGL 3.0… but no support or docs for X.org devs … (X.org is the windowing system used by Linux)
ATI - closed source support, which is not as good as nvidia but has OpenGL 3.0 support. They also provide docs and developers for open source drivers. Since a while closed source driver supports just the r600 r700 series while r100-500 users are forced to use the open source driver. Open source driver is stable and nice (I’m using it) but has about 50% performance of closed source catalyst and is currently limited to OpenGL 1.3 or 1.4
Intel - provides both docs and devs for open source dirvers. Their driver supports OpenGL 1.4 …
The only chips that may not have any OpenGL support are maybe some VIA GPUs or very old ones … That said Intel , Ati and Nvidia support Linux so I guess about 99% of Linux users do have accell
That being said Loki games (R.I.P) was able to port using SDL many 2d games (and Homm3 too) to Linux and they didn’t need to use OpenGL … I really do not see any reason for a 2d game to require hardware 3d acceleration. For example Battle for Wesnoth uses SDL and can work with larger resolutions then 800x600 and doesn’t “eat up” the CPU