Jump to content
Eternal Lands Official Forums

m_bee

Members
  • Content count

    492
  • Joined

  • Last visited

About m_bee

  • Rank
    Leprechaun
  1. More compact inventory

    Forgot to post here yesterday. BerliOS stuff cleaned to patch cleanly against the new release of the client. Nothing else changed, just that, so, you can still test it patched against the latest client.
  2. About arenas

    If we are going to go the historical way, lets go on a complete manner The old arenas, as they were, were not a safe place for anyone inside. Some times, if the people that were pesent had honour, the combatants would fight on equal conditions to death, some other, if there were any other interest in the middle, you could be easily ripped up by a friend of an assassin or group of them hired for that purpose by your enemy or his boss. Sometimes, you could even be killed on a colisseums depending if the public liked you or not... Now to the game again, pvp is by far the best way to make experience, so, what is the problem is you take some risk? if even now with that risk, prople continue pvp'ing cause is the best exp for fighters... You want easy and safe exp? Go make metal bars. If you choose to fight, then... well, fight Said that, im not a pker, and rarelly go into any pk map. I understand the concept of honour in the arena, but... well, this is like real life, some people have it, some does not, but if you go into a battle ring, you know that you can get some damage in your bones, so, if you are not prepared to go against Al Capone, better stay away from him
  3. Linux - Direct Rendering :NO

    Yeah, you can also try different combos, enabling and sisabling your native agp support for your chipset, or using the builtin... A did millions of combinations with many ATIs, and found only one real thing: it might work or not at all depending on your card. And, if it works, the setup is different for each card. That is why no guide can be followed. ATi just sucks, if you can afford it, sell your card and buy a Nvidia. Any Nvidia will do the job, you will see
  4. Problem in install Ubuntu AMD64 (64 Bits)

    Not likely, since the libraries are things that are very different on each distro. The only solution would be to include in the package the libs, and provide those for all the archs, wich I think Entropy might not be willing to do. You need openal, freealut, the xlibs, libxml2 and cal3d 0.10.0 (no other version will work ok). You also need, of course, sdl and sdl-net. I think i did not forget anything, but it is possible
  5. Problem in install Ubuntu AMD64 (64 Bits)

    Sure, you need to fetch the sources using the instructions in berliOS, for the password, you just need to press enter (or "anonymous" i dont remember right now). Once cvs ends, you will have a dir with the client sources. You need to edit the Makefile.linux file, change the arch to k8, amd64 or athlon64 (the three are the same thing), and then edit the LD line to match this one (just added -lalut at the end). LDFLAGS=$(shell sdl-config --libs) $(shell xml2-config --libs) -lSDL_net -lopenal $(XDIR) -lGL -lGLU -lvorbis -lvorbisfile -lcal3d -lm -lpng -lalut Of course, you first need to locate the correct package for freealut and install it, including the dev package if there is a separate one for that stuff. Otherwise, the linker will fail with a lib not found error.
  6. Problem in install Ubuntu AMD64 (64 Bits)

    Not amd64 related at all. Openal splitted into openal itself and freealut since version 0.8. So, if you updated openal recently you will need to recompile the client yourself and add -lalut to the linker. That, or downgrade openal to any 2005.... release. EDIT: Of course, if you decide to recompile linking against any openal version greater than .8 you will need to install freealut separatelly.
  7. What is your political compass score?

    You could find my opinion about politics by doing cat /dev/null or using the command ":" in linux But I really hate any radical thing, and politics is not an exception. For me the politics have a circular structure, and if you go to the left too much, you appear in the extreme right
  8. need a simple patch tested

    No problems here so far. Never saw that problem and nothing changed for now... I ll test a bit more and report if I find something.
  9. NEW_SOUND

    Yes, that is what I thought. Anyway, in that regard, the 2005xxx versions would be the same. They also include the alut stuff into the same openal package. It is from numbered versions (first release was 0.0.8 for gentoo, dunno for other distros) when it splitted into openal + freealut. And that, as I say, only creates more trouble, though an very easy to solve one... But, as we both agree, I doubt that is the issue. Other than that linking issue, I did not have any problem in the past with any version of openal. For the rest, the unstable branch of debian should not be a problem, since the client compiled fine and worked fine until that patch was included, did not it? So, the issue is openal, and the patch code.
  10. NEW_SOUND

    True, in fact, 0.2004090900-1 is maybe too "stable" and quite old. Anyway, I doubt is has anything to do with the problem. The elc makefile is not prepared to deal with the new releases of openal, due to the fact that it splitted in openal itself + freealut, and -lalut is needed to be added to linker option in the makefile for it to be able to compile fine. Anyway, there are quite a few 2005... releases and that one that you use is very outdated. I dont know how debian is right now in this regard, since I left debian some time ago in favour of gentoo. To talk about unstable debian is, anyway, like to talk about a slow athlon cpu... It does not exist in a strict manner, even if the distro is labeled that way
  11. Yeh, misleadding newcomers is baneable. But make sure you can backup your statements with proofs, for example, the chat_log.txt part where it did that thing, before calling any moderator. Usually, they dont like to waste their time.
  12. Ok, that reason seems fair enough for me. Well, i am not too knowledgeable in opengl -and nothing at all in directx hehe- but for the little I know, you can just read the texture from a file and then use, for example, gluBuild2DMipmaps() or any other similar opengl function to make the mipmap. In that regard, I dont think there is any difference at all. But I dont know if the client uses any other fancy stuff, I would need to look deeper, since I neven looked at the renderer code. I did some quick search in the gl_init code, and it seems that the EL renderer uses some kind of custom function, that surelly is based in those opengl primitives -and it is important that they are opengl primitives, since the standard opengl primitives are the ones that the hardware acceleration can run in a breeze, since they are coded in the video hardware-. I dont think that the graphics format has anything to do, unless there is something that opengl supports natively that I am not aware off (wich, on the other hand, is perfectly possible ). I dont know either if directx has such support that you mention, it might be... but directx is not cross platform, and is not accelerated by most video hardware either, do, it is not an option (no one would want to code such thing for ELC, anyway, since opengl is good, standar, solid, and well supported in many platforms and by all video hardware manufacturers). So, I would say (again, my knowledge is very limited in this things) that the texture format has nothing to do with the use of mipmaps. Since the texture is loaded into an array of bytes, and then processed to create the map by opengl functions. Anyway, there are people around here that could explain this far better than me, and, possible, make some corrections on this that I said. Cheers
  13. All de devs, including graphists, should care about this. The interface is the first thing that a person sees when entering this game -or any other game, in general. Let me explain myself in a softer manner. Bugs are not only compile-time bugs, or incorrect values or layout in the screen, or issues directly related to the programming thing. Interface bugs also exists. If a thing works, it is supposed to work most times and under all possible circunstances in the best possible way. If you provide an option -F6- to change the interface in any way, it is also supposed to work. And an "I dont care since it is optional" does not remove the bug. It is still there, just hidden, but it is there. The obvious solution, would be to remove the F6 thing from the client. Simple bitmaps with simple transparencies and no blending on their surroundings will not differ much in that matter from not having an alpha channel. You can think of the alpha like of an additionanl bmp file with the mask, it the file has two colours and no grandients -aka blending- the compresion on png will make the alpha channel size ridiculous. That will open possibilities like adding light/tinting effects on object if you pick them and things like that in the future. Or even in door when you hover them... just imagine. Of course, we would still need the masks for the clock and compass to fix the weirdness in the hud, and that is why you should worry about this It does not matter if it is in a mask file or we have a png with alpha channel, it would need to be done. Of course, the decission is from both of you, owners and creators of the game. I was just a bit surprised that we are using libpng just for a marginal functionality, and that is why I though of reviving this thingie and hear opinions from you and the rest of contributors to the client code. PS: BTW, to put at least 16bits images in the minimaps wouldnt hurt, anyway, but that is a secondary thing that I dont care too much at all about. Still, it would look nicer.
  14. There are two ways to make the HUD look well. 1.-Using masks, hard to implement, lots of new code, probably bugs, and separate files for the mask and pictures, wich is another problem. Plus, as ttl said, images with few colours have a good compression ratio with png, while bmp is 258k size in 512x512x8bits, it does not matter wich file you choose, since there is no compressions at all. The size of the pack is larger, that is another handicap of the bmp format. 2.-Using native alpha support present in png, as ttl also well said, the alpha is in the same png file, as a sort of transparency, no need to use masks, cleaner code, faster develpment, no bugs due to that part of the code that draws the transparency using the alpha channels, since the suport is in libpng ans well tested. Of course, the other option is to leave the HUD remain crappy forever. Choice is yours as always Another thing, is that you will have the real transparency support for the icons in the enciclopedia, inventory and the rest of windows (no more black backgrounds). Of course, images would need to be edited to include the alpha, but that is a trivial task in anything like photoshop or the gimp. And saved as png. An example that you can check easy, Roja. A tipical example is that in html pages PNGs are needed when the image above has to let you see some parts of the image behind it, only png can do this. Jpg and bmp do not support transparencies at all. This would make the possibilities regarding the customization and fancyness of the interface a lot more nicer than they are right now, if you ask me, that is an advantage. In the html example, if you dont want to use pngs, you need to paste the buttons of whatever in your graphics editor, melt it with the background so the transparent effect is archieved as a fake, wich will look like crap is the relative position of the back and fore images is changed a bit (and that, in web stuff is always since each browser does the things its own way). Anyway, you have the last word, but... if png is going to be used for that crap only, I would remove it from the code. No one needs libpng as a screenshooter, it is like liking against directx to add a screenshot function, weird. IMO. EDITes for typos.
  15. Well, I think that to use that png support would be better, because of the image quality and the file size, but that is my opinion, of course. Anyway, then the only objetive of the png support was to include a function to make screenshots? That is a thing that I cant just understand... Cause then bmp would be equally valid for that purpose... EDIT: Plus the fact that I cant understand why are we adding an additional dependence to link against libpng.so /dll if we can do it in bmp and it just works well.
×