Some speedup

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

Excuse me but you just seem to be an Allegro fanboy… does it have any drawbacks :-> ? I’ll look for more balanced opinions on Allegro, but I think that SDL + openGL is a better option.

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.

What is the rational behind moving to OpenGL ?

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)

@ubuntux

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.

It’s not a linux issue, it’s more of a “people-not-willing-to-use-non-free-technology”-issue…
(free as in stallman’s definition, not as in beer)

I’m curious if CPU technology is free as in Stallman’s definition.

@Tow Dragon:
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

There is 2D hardware acceleration. As for not supporting openGL everywhere, it’s more a manufacturer issue when they refuse to provide drivers or even docs. Closed source drivers are also usually of poor quality (at least on linux).

I tried 1024*768 and it’s running as fast as my emulated H3 windows version in 800x600, as long as I use the right screen depth.

The move to openGL will also prevent vcmi from running on a wide variety of handheld devices. Will it be possible to keep SDL at the same time ?

AFAIK Stallman cares only (or rather mostly) about software not about hardware. That means the software that makes use of CPU and makes it “work” should be free in his opinion, but technology behind the CPU doesn’t have to be free…

There are some open CPUs or GPUs though if you are interested:
en.wikipedia.org/wiki/Open_hardware
One very efficient and prominent technology here is Sun SPARC architecture, which provides great CPUs.

As stated in my post above I agree with you. 3d accel should not be needed for a 2d game … If screen depth is the problem there should be some hack for it ? Maybe asking Battle for Wesnoth devs about it would be a good idea ? I mean they use SDL but do not have performance problems in higher resolutions

[EDIT]

Also here are some screens from Loki game version of H3 … It’s a native SDL Linux version working at 800x600 … Judgning by the CPU use I think SDL can do it and there is no need for OpenGL :

s1d2.turboimagehost.com/t/1725026_as24.png s1d2.turboimagehost.com/t/1725027_as23.png s1d2.turboimagehost.com/t/1725028_as22.png
It’s on a amd turion x2 laptops running at 800 Mhz as it didn’t need to switch to full power 1700 MHZ… Considering that I think optimization or not Vcmi for sure can do better with SDL. I think something is wrong somewhere as Loki didn’t have lot’s of programers to do great optimization either.

I don’t know in what condition it is. I don’t play games on Linux. I just don’t have any reason to think that ubuntux is lying.

It’s just a simple consequence of ubuntux’s statement about openGL support in Linux distributions.

I just believe that what ubuntux has written is true… please point out where I say more than he said about Linux.

So my only fault is that I haven’t checked if his words are true… so I don’t know why you fucus on my post instead of his.

So there is nothing wrong in having openGL 1.3 or even 1.4 drivers as a requirement… or should I check it on myself to not be harassed by other Linux users who think it’s not true?

Handheld devices could have not enough memory for VCMI… you need at least 256 MB to be sure to run VCMI with any map. Additionaly maintaining two renderers at the same time would be harder, make code uglier and need more support. I’m not sure if it’s good option.

It’s interesting… there are a few other heroes III remakes and some of them use openGL for rendering. It’s just faster and more powerful. It’d make it possible to add some interesting graphical effects easily such as adventure map scaling. Anyway, the decision hasn’t been made yet, we’re just considering the use of openGL.

But they could just have well optimized code of Heroes III.

Btw, while we’re at portable devices: I’d love to see VCMI on the Pandora one day, so if you decide to use OpenGL, could you try to keep the code OpenGL ES compatible?

@Tow Dragon:

From reading that your conclusions are :

So you see Ubuntux said that some Linux users do not have OpenGL support … He was wrong at the fact that there are almost no open drivers and the emulation thing (as more cards are supported by open drivers then by the blobs), but he did clearly mention the blobs from ATI and NVIDIA.

Your conclusions from this statement imply that :

  1. Linux doesn’t have any OpenGL accell in every significant distro.
  2. Linux developers are incompetent.
  3. Linux sucks and is unable compete with technology from 10 years ago.

My point was not to harass you. I just felt that your argument here was emotional and out some unknown superstitions against Linux … I posted about it an civil way not calling you names or doing anything else that one could call harassing . Sure my response is harsh but I feel that your statement is also harsh and unjustified.

Interesting … However wouldn’t it make objects blurry ? I mean those are just 2d sprites not 3d models so scalling would blur them at some point ?

Would moving to openGL speed up Vcmi development ? or would it slow it down ? One other benefit could be using OpenGL effects for spells (which in case of going standalone at some point would free a lot of stress of doing new spell animations)

BTW are those other remakes advanced projects ? Why not join forces with them then ?

Yes of course they did have it … as they ported it to Linux. Nevertheless as I said free games like Battle for Wesnoth use SDL and work just fine at big res, and I don’t think they do some enormous optimization work.

[EDIT]
If you go OpenGL road I think OpenGL1.3 should be max, because some older cards do not support OpenGL 2.0 just 1.3 … like for example Radeon 9200 … You may call it old but for many those are enough and IMHO it would be a bit strange if a game like HoMM3 could not run on those … wouldn’t it ? and yes that limitation is also for Windows since the chip has support for 1.3 specs … Of course it still can run OpenGL 2.0 games but all 2.0 instructions are emulated thus very slow. Consider also laptop users which in many cases do not have great GPUs … For example my quite new laptop has a card that has just OpenGL 2.0 support …

so the best choose is to use library which could use many differ acceleration libraries, such as allegro (can sdl do that easily?).
ie. in allegro in most cases the only thing to change between rendering sources is the change argument for the initialization function. Standing on that every machine/system has to be compiled separately, you simply can choose that some types of rendering are unavailible (ie. DX on linux), whithout greater mess (#IFs on #includes and some function to prevent choose unavailible mode)
allegro even has easy way to reinitialize graphics in middle runtime ie. pregame may be in 800x600 no-accel and ingame may be DX or GL in one of known resolutions, all based on config. switching between windowed and fullscreen versions is easy too

Firstly, he mentioned them so there must be a significant number of them. They use certain Linux distributions - if all of them use exotic distros but together thay make a significant group then I’ve mistaken. But:

Ubuntux wrote that sometimes drivers do not exist… so what’s wrong with this?

I haven’t wwritten why they are not able to provide it. Maybe they just don’t have enough time?

Linux is certainly able to compete with many modern MS technologies. Besides, I’ve also better reasons to don’t like Linux than this one. It’s interesting that the only set of applications that works flawlessly in Linux for me is shell (usually I use bash, sometimes tcsh and sh).

Actually it was a bit emotional, I’ve even posted an emoticon :). I had bad experience with Linux.

Yes, they would be blury but it wouldn’t be a big problem if used only for a preview of a bigger area.

It dependds on how many problems it would make and how much time we would save on optimization of SDL renderer.

In fact you can always make such animation in another application and convert it to def… but doing everything in openGL in VCMI could be more simple.

Only one of them is quite advanced, but it’s developed in Delphi and the programmer is not intreested in helping us. The rest of them are much less advanced then our first publicaly released version.

Everybody has certain reasons to not join forces. One of those projects is developed by our former programmer who just thinks that our code is very ugly and prefers to start from scratch.

Nvidia provide very good drivers for GeForce cards and this work very well like in windows, I tested some games.

About “Battle for Wesnoth”, realy fantastic game, I downloaded this yesterday and this worked very fast. But see, here is more differences between BoW and VCMI. BoW don’t have a lot animations, all objects in maps are constant. Well, this game don’t need refresh screen all the time, only “move” object. And in VCMI a lot of object are animated, tress, buldings etc. Anyway, BoW had awesome engine in SDL.

I think OpenGL in VCMI can help, and if it’s fast way to improvement performace, why not ?

I don’t really get from where this conclusion can be drawn … I’ve re-read all ubuntux post in this topic and I really do not know.

When you use Linux you should buy hardware with consideration of it. Even if 99% of hardware has at least basic OpenGL support the 1% is really the fault of users because they bought unsupported hardware.

With that we should close this topic

That’s why I posted about HoMM3 version by Loki … It’s in SDL and can work on a 100- 200 Mhz CPU judging from the cpu use (just as original h3 can) … The stated goal of Vcmi team was to work on a 500Mhz CPU and in my maybe limited understanding I see it happening without some heavy and hard optimization…
As ubuntux wrote just changing the screen depth made a big difference …

That said I’m not against OpenGL … I just don’t see big benefits of using it unless some 3d objects/effects are used in this game. Furtermore going OpenGL somewhat adds extra development time to port the existing code to it and make new graphic subsystem. So in the long run it means the first playable release of VCMI will move in time even further.

Thanks, but I’m not going to start using Linux for my everyday tasks soon.

I agree with this, Windows is far from being perfect - but works very well for me. If only it were as customizable as *nix systems…

I hope nobody will scare away because of my comment. Linux users are important for me and I don’t want to discriminate them because of my OS preferences.

I think Delphi was quite popular some time ago, but undoubtly its popularity decreased lastly. Modern programming tend to have C-style syntax (C++, C#, Java) tend to have C-style syntax instead of Pascal-style syntax.

apropos allegro… look where on sourceforge.net rank lists is allegro and where is sdl, so if believing that allegro rulez over sdl !!! allegro is an library with great history, and have many addons made by various people, contain all needed i/o (keyboard, mouse, timer, joystick, graphics, midi sound, waveform sound, file i/o, access to system specific objects, simple gui routines) and even math functions, easy to use, but nice controllable for PROs (in more sophisticated version)…

but looking how you write VCMI it can be some more time than just a week to port vcmi, but we can define inter-interface between existing sdl-optimized functions and allegro layer to ease porting

memory bitmaps are base objects for image manipulation in allegro, and support vary types of bitmaps by the same BITMAP* object, contains easy primitives drawing and even simple 3d support, has built-in directx support on windows version, and in allegro code for specific gfx-library could frequent be ported to another gfx-library by simple few lines definition based preprocesor script.

color palette operations could be ther automatised without leaving out control on it, so make drawing heroes-specific 256-color bitmaps easier than in sdl-extension you wrote

LOOK AT THIS

Name Relevance Activity Rank Registered Latest File
Allegro game programming library 80.81% 99.81% 478 2000-05-13 2009-05-04
sdl 61.09% 99.50% 1,263 N/A N/A

RANK (lower better) allegro 478 vs sdl 1263 - so coooool!!!