Anonymous | Login | 2024-11-21 19:19 UTC |
My View | View Issues | Change Log | Roadmap |
View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||
0000958 | VCMI | Sound, music, videos | public | 2012-05-16 08:23 | 2014-05-30 17:41 | ||||
Reporter | douggie_m | ||||||||
Assigned To | Ivan | ||||||||
Priority | normal | Severity | minor | Reproducibility | always | ||||
Status | closed | Resolution | fixed | ||||||
Platform | PowerPC (Big Endian) | OS | GNU/Linux | OS Version | Debian Sid | ||||
Product Version | 0.88 | ||||||||
Target Version | Fixed in Version | 0.89 | |||||||
Summary | 0000958: Wrong colors in some places on map and inside town screen | ||||||||
Description | I built VCMI 0.88 release tarball, extracted the required .lod files and etc. from WoG 3.58f distribution, and: 1. Good news - it works! 2. Bug - it shows wrong colors in some places. Screenshot is attached. | ||||||||
Steps To Reproduce | Just start any map, and you'll see it. I suppose it is endianess bug, i.e. you may not see it on x86 (endian little architecture). | ||||||||
Tags | No tags attached. | ||||||||
Attached Files | Screenshot - 05162012 - 03:55:10 AM.png [^] (602,045 bytes) 2012-05-16 08:23
Screenshot - 05162012 - 04:32:46 AM.png [^] (1,313,869 bytes) 2012-05-16 08:42 Screenshot - 05162012 - 10:55:00 AM.png [^] (566,759 bytes) 2012-05-16 15:03 Screenshot - 05162012 - 12:09:17 PM.png [^] (1,004,074 bytes) 2012-05-16 16:17 Screenshot - 05162012 - 03:44:29 PM.png [^] (1,014,023 bytes) 2012-05-16 19:49 Screenshot - 05162012 - 03:57:26 PM.png [^] (535,715 bytes) 2012-05-16 19:59 Screenshot - 05162012 - 04:36:22 PM.png [^] (1,022,548 bytes) 2012-05-16 20:38 endianless_patch.patch [^] (4,546 bytes) 2012-05-16 21:18 [Show Content] endianless_patch_corrected.patch [^] (33,615 bytes) 2012-05-16 21:29 [Show Content] Screenshot - 05162012 - 05:49:19 PM.png [^] (1,648,970 bytes) 2012-05-16 21:51 Screenshot - 05172012 - 03:35:32 PM.png [^] (1,325,600 bytes) 2012-05-17 19:38 endian-minimap.patch [^] (4,364 bytes) 2012-05-17 22:48 [Show Content] Screenshot - 05182012 - 05:15:18 AM.png [^] (31,139 bytes) 2012-05-18 09:17 Screenshot - 05212012 - 12:30:10 PM.png [^] (1,355,805 bytes) 2012-05-21 16:33 Screenshot - 05222012 - 01:02:36 PM.png [^] (1,658,304 bytes) 2012-05-22 17:09 Screenshot - 05252012 - 03:03:15 PM.png [^] (1,679,065 bytes) 2012-05-25 19:11 | ||||||||
Notes | |
(0002445) douggie_m (reporter) 2012-05-16 08:34 |
Attaching another screenshot (showing the town screen). |
(0002447) Ivan (developer) 2012-05-16 12:15 edited on: 2012-05-16 12:36 |
Looks like endianess bug indeed. Will check. This is not required but will be helpful. Can you compile VCMI using latest sources from SVN? It won't fix bug right now but I have no other way to check how my fix will work. |
(0002449) douggie_m (reporter) 2012-05-16 13:23 edited on: 2012-05-16 14:06 |
> Can you compile VCMI using latest sources from SVN? Why not. I tried (current) revision 2682 and this issue is still present. |
(0002450) douggie_m (reporter) 2012-05-16 14:59 |
I did commented out the following in client/CbitmapHandler.cpp:84 #if 0 /* (SDL_BYTEORDER == SDL_BIG_ENDIAN) */ tp.b = pcx[it++]; tp.g = pcx[it++]; tp.r = pcx[it++]; #else tp.r = pcx[it++]; tp.g = pcx[it++]; tp.b = pcx[it++]; #endif and some parts started to be painted correctly (like chosen hero's portrait, bottom resources line, in-game message dialogs, etc.). Screenshot will follow. |
(0002451) Ivan (developer) 2012-05-16 15:06 edited on: 2012-05-16 15:07 |
Yup. Found that one too - it should fix all blue-ness. Yellow-ness most possibly is coming from client/SDL_Extensions: Here we have several ColorPutter::putColor methods. Problem is: color with RGB = 222, 243, 255 (Font that supposed to be white) after blitting turns into RGB = 243, 255, 0 (First component missing) And there is one more separate issue - minimap. |
(0002452) douggie_m (reporter) 2012-05-16 15:15 |
Well, SDL says: > Warning: SDL says that 24bpp is wrong and suggests 32 That zero comes from alpha (or "unused"), I suppose. |
(0002453) Ivan (developer) 2012-05-16 15:23 |
It means that there is mismatch between X color resolution and in-game one. Shouldn't affect game in any way. If you wish to remove that warning open file ~/.vcmi/config/settings.json and add this line in "video" section: "bitsPerPixel" : 32, Ok. Bug is in ColorPutter::PutColor method in SDL_Extensions.h:238 Now looking for a way to fix... |
(0002454) douggie_m (reporter) 2012-05-16 15:34 edited on: 2012-05-16 15:51 |
I'm testing with else if(incrementPtr == -1) { ptr -= 4; ptr[0] = B; ptr[1] = G; ptr[2] = R; if (bpp == 4) ptr[3] = 0; No, this was a bad idea ;) This variant: if (bpp == 4) { ptr -= 4; ptr[0] = B; ptr[1] = G; ptr[2] = R; ptr[3] = 0; } else { ptr -= 3; ptr[0] = B; ptr[1] = G; ptr[2] = R; } Does produce the same result as original. |
(0002455) Ivan (developer) 2012-05-16 15:49 edited on: 2012-05-16 16:01 |
Try replacing that method with this code: { Uint8 *ptr2 = ptr; if(incrementPtr == 0) { if(bpp == 4) *ptr2++ = 0; ptr2[0] = R; ptr2[1] = G; ptr2[2] = B; } else if(incrementPtr == 1) { if(bpp == 4) *ptr2++ = 0; *ptr2++ = R; *ptr2++ = G; *ptr2++ = B; ptr = ptr2; } else if(incrementPtr == -1) { *(--ptr2) = B; *(--ptr2) = G; *(--ptr2) = R; if(bpp == 4) *(--ptr2) = 0; ptr = ptr2; } else { assert(0); } } |
(0002456) douggie_m (reporter) 2012-05-16 15:53 edited on: 2012-05-16 15:59 |
> First byte is unused\alpha ... After this - 3 RGB bytes That means that the color format is ARGB and not RGBA? > Try replacing that method with this code Okay, trying it now. By the way, shouldn't we restore `ptr' back after incrementing it? |
(0002457) Ivan (developer) 2012-05-16 15:58 edited on: 2012-05-16 16:02 |
Looks to be so. That's the only way I found to get such image Note: I've edited above code. Previous version could crash. Yes. ptr should be restored if increment != 0. My bad. |
(0002458) douggie_m (reporter) 2012-05-16 16:02 edited on: 2012-05-16 16:05 |
Your new version doesn't increment/decrement for +1/-1 cases. I'm trying previous one with if(incrementPtr == 0) { if(bpp == 4) *ptr++ = 0; ptr[0] = R; ptr[1] = G; ptr[2] = B; if(bpp == 4) ptr--; } UPD: You fixed it one more time ;) These edits make me crazy. |
(0002459) douggie_m (reporter) 2012-05-16 16:10 |
Very nice. Now yep, minimap left. |
(0002460) Ivan (developer) 2012-05-16 16:34 |
Sorry. Will try less edits next time :) It seems that in all cases (map, shadows, button frame) blue component is incorrect. Looking into this issues right now. |
(0002461) Ivan (developer) 2012-05-16 16:44 |
Ok. Previous two methods: lines 207 and 229 1) Add at start: Uint8 * ptr2 = ptr; if (bpp == 4) ptr2++; 2) Replace all access to ptr as array to ptr2: ptr[0] -> ptr2[0] ptr[1] -> ptr2[1] ptr[1] -> ptr2[2] No need to update ptr after this. This should fix at least some issues. When everything will be fixed I'll make better patch that will work on both little and big-endian systems. |
(0002462) douggie_m (reporter) 2012-05-16 16:48 |
> It seems that in all cases (map, shadows, button frame) blue component is incorrect. Looking into this issues right now. On the last screenshot map and shadows look nice for me. Button frame is little emo-ish, yeah. By the way, can you upload screenshot to see how it *should* look like? |
(0002463) Ivan (developer) 2012-05-16 17:00 |
By "map" I meant "minimap" http://forum.vcmi.eu/album.php [^] - VCMI screenshots, some may be outdated http://dl.dropbox.com/u/22372764/vcmi/vcmi-current.png [^] - my screenshot of this map |
(0002464) Ivan (developer) 2012-05-16 17:22 edited on: 2012-05-16 17:31 |
This is what I have right now: 4 modified ColorPutter methods, lines 205-285: Sorry. Missed few ptr2's http://pastebin.com/9j1WJfUt [^] |
(0002465) douggie_m (reporter) 2012-05-16 19:27 edited on: 2012-05-16 19:35 |
> error: ‘Uint’ was not declared in this scope (I changed them to Uint8) And please, use `diff -u' next time to easily feed that to `patch'. UPD: I used your patch, but minimap is still the same. |
(0002466) douggie_m (reporter) 2012-05-16 19:48 edited on: 2012-05-16 20:12 |
Look what I've found, CAdvmapInterface.cpp: --- client/CAdvmapInterface.cpp.orig 2012-05-16 15:36:39.248625059 -0400 +++ client/CAdvmapInterface.cpp 2012-05-16 15:42:35.787735261 -0400 @@ -77,16 +77,16 @@ vinya.first = m["terrain_id"].Float(); const JsonVector &unblocked_vec = m["unblocked"].Vector(); - vinya.second.r = unblocked_vec[0].Float(); - vinya.second.g = unblocked_vec[1].Float(); - vinya.second.b = unblocked_vec[2].Float(); + vinya.second.r = 255; //unblocked_vec[2].Float(); + vinya.second.g = 255; //unblocked_vec[1].Float(); + vinya.second.b = 255; //unblocked_vec[0].Float(); vinya.second.unused = 255; colors.insert(vinya); const JsonVector &blocked_vec = m["blocked"].Vector(); - vinya.second.r = blocked_vec[0].Float(); - vinya.second.g = blocked_vec[1].Float(); - vinya.second.b = blocked_vec[2].Float(); + vinya.second.r = 255; //blocked_vec[2].Float(); + vinya.second.g = 255; //blocked_vec[1].Float(); + vinya.second.b = 255; //blocked_vec[0].Float(); vinya.second.unused = 255; colorsBlocked.insert(vinya); } I first tried to swap rgb <-> bgr, but this gave me no better results. But setting them to 0xFF makes minimap be white, except castles, heroes, and emo ;) border. Maybe this can help. Screenshot follows. UPD: `vinya.second.r = 255; vinya.second.g = 0; vinya.second.b = 0;' makes minimap the same emo magenta as the border (and *not red*). UPD2: green=255, r,b=0 gives cyan color; blue=255, r,g=0 gives... no, not yellow, but clean blue! r,g,b=0 gives the same blue too. Note: magenta is R=FF, G=0, B=FF; cyan is R=0, G=FF, B=FF. |
(0002467) Ivan (developer) 2012-05-16 20:14 |
Looks to be same problem as yellowness. Will try to make sense of it later - it's quite late here. Tomorrow I'll finish "endian-friendly" patch and will re-check every place with direct access to images. If I won't miss anything then all you'll need to do is to re-check subpixels order. One question - have you set bits per pixel in config to 32? Or you're using default value (24)? |
(0002468) douggie_m (reporter) 2012-05-16 20:21 |
> have you set bits per pixel in config to 32? Or you're using default value (24)? I'm following the rule "Warnings can be ignored" ;) So I haven't change anything. |
(0002469) douggie_m (reporter) 2012-05-16 20:30 |
I found how it is drawn, it is "SDL_PutPixelWithoutRefresh", part of the same "SDL Extensions": void CSDL_Ext::SDL_PutPixelWithoutRefresh(SDL_Surface *ekran, const int & x, const int & y, const Uint8 & R, const Uint8 & G, const Ui$ { Uint8 *p = getPxPtr(ekran, x, y); getPutterFor(ekran, false)(p, R, G, B); //needed? if(ekran->format->BytesPerPixel==4) p[3] = A; } |
(0002470) douggie_m (reporter) 2012-05-16 20:36 edited on: 2012-05-16 20:53 |
Bingo! It is "not needed" actually. Just commenting out if(ekran->format->BytesPerPixel==4) p[3] = A; gave me cool minimap! UPD: By the way, I know why other SDL-games are blueish now ;) They do use these SDL_Extensions, which seems to be popular. Is there devs for them? If so, these changes shall be reported to them. |
(0002471) douggie_m (reporter) 2012-05-16 21:17 edited on: 2012-05-16 21:52 |
Attaching patch against current SVN (2684). UPD: oops UPD2: attached screenshot with the game built with endianless_patch_corrected.patch applied to fresh svn; game is 100% playable now Great work! Thanks, Ivan. |
(0002473) douggie_m (reporter) 2012-05-16 22:20 edited on: 2012-05-17 21:19 |
OOPS, I started to actually play a game, but... It does segfault on each battle! Is this known issue? Shall be reported separately? -------------------------------- Warning: empty path found... Segmentation fault Server finished Lost connection to server, ending listening thread! read: End of file Something wrong, lost connection while game is still ongoing... terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::system::system_error> >' what(): read: End of file Aborted -------------------------------- GDB gives me: -------------------------------- Program received signal SIGABRT, Aborted. [Switching to Thread 0xec50b450 (LWP 12163)] 0x0de9098c in *__GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 64 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory. (gdb) bt #0 0x0de9098c in *__GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #1 0x0de96040 in *__GI_abort () at abort.c:92 0000002 0x0e16a9d0 in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib/powerpc-linux-gnu/libstdc++.so.6 0000003 0x0e1679e8 in ?? () from /usr/lib/powerpc-linux-gnu/libstdc++.so.6 0000004 0x0e167a2c in std::terminate() () from /usr/lib/powerpc-linux-gnu/libstdc++.so.6 0000005 0x0e167ed8 in __cxa_rethrow () from /usr/lib/powerpc-linux-gnu/libstdc++.so.6 0000006 0x1035319c in CClient::run (this=0x1119d0f0) at Client.cpp:162 0000007 0x10448c30 in boost::_mfi::mf0<void, CClient>::operator() (this=0x111a3574, p=0x1119d0f0) at /usr/include/boost/bind/mem_fn_template.hpp:49 0000008 0x10448a38 in boost::_bi::list1<boost::_bi::value<CClient*> >::operator()<boost::_mfi::mf0<void, CClient>, boost::_bi::list0> ( this=0x111a357c, f=..., a=...) at /usr/include/boost/bind/bind.hpp:253 0000009 0x104488d8 in boost::_bi::bind_t<void, boost::_mfi::mf0<void, CClient>, boost::_bi::list1<boost::_bi::value<CClient*> > >::operator() (this=0x111a3574) at /usr/include/boost/bind/bind_template.hpp:20 0000010 0x10447cfc in boost::detail::thread_data<boost::_bi::bind_t<void, boost::_mfi::mf0<void, CClient>, boost::_bi::list1<boost::_bi::value<CClient*> > > >::run (this=0x111a3470) at /usr/include/boost/thread/detail/thread.hpp:62 0000011 0x0e49c40c in ?? () from /usr/lib/libboost_thread.so.1.49.0 0000012 0x0de247b0 in start_thread (arg=<optimized out>) at pthread_create.c:306 0000013 0x0df4ab10 in clone () at ../sysdeps/unix/sysv/linux/powerpc/powerpc32/clone.S:123 -------------------------------- UPD: it does actually look like bug in either GLibC or Boost. UPD2: to double-recheck, I built fresh svn^W 0.88 release w/o this patche, ignoring colors issue; and I was able to play battles. |
(0002474) Ivan (developer) 2012-05-17 10:48 |
I'm back. SDL_Extension is part of VCMI but I suppose most of SDL-based projects have similar code. SDL itself provides only basic functionality. You patch won't work as it because it will mess up on little-endian systems. I've applied all your fixes in endian-independent way - update to rev 2685. It should work without any glitches and without any additional patches. Some areas to re-check: - shadows. They should be gray, not green as on your screenshots - puzzle map. Find some obelisks on map - opened areas should look like old photo (sepia effect): http://forum.vcmi.eu/album_pic.php?pic_id=39 [^] - battles. - town and town fort windows. |
(0002478) douggie_m (reporter) 2012-05-17 19:08 edited on: 2012-05-18 08:51 |
> I've applied all your fixes in endian-independent way - update to rev 2685. It should work without any glitches and without any additional patches. Great! I checked out and is ready to build fresh revision 2686. Hang about a half of hour for the test report ;) > - shadows. They should be gray, not green as on your screenshots --They are green. ++Shadows are gray now. Neutral-owned stuff on minimap is still green with r2686. UPD: By the way, owned-by-player minimap's stuff is black, not red (as on your screenshots). > - puzzle map Looks fine. See screenshot. > - battles Crash. terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::system::system_error> >' > - town and town fort windows. They are all fine. |
(0002479) douggie_m (reporter) 2012-05-17 20:22 |
> SDL_Extension is part of VCMI but I suppose most of SDL-based projects have similar code. SDL itself provides only basic functionality. Ah, okay. At least, I know where to start to dig [spoiler]for the Grail[/spoiler] ;) |
(0002480) Ivan (developer) 2012-05-17 20:50 |
Nice! Screenshot looks fine - even shadows on snow are gray as they should. Not sure what's wrong with minimap. Will check. Regarding crash - this looks like crash on server. Before starting a battle attach debugger to vcmiserver process. This should show real location of the crash - system_error/ End of file usually means that client lost connection with server. |
(0002481) douggie_m (reporter) 2012-05-17 21:19 |
Regarding crash on battle - the last working one I tried was 0.88 tarball actually, not svn. I can try git-svn and then git bisect. |
(0002482) Ivan (developer) 2012-05-17 21:35 |
git bisect may help. Or may not - some of our commits are quite large. Stacktrace from server should be more easier to check. And I think I fixed minimap issue. Will commit fix a bit later. |
(0002483) douggie_m (reporter) 2012-05-17 21:52 |
> Stacktrace from server should be more easier to check. Okay, you convicted me to spend some time with gdb ;) |
(0002484) douggie_m (reporter) 2012-05-17 21:57 edited on: 2012-05-17 22:00 |
> I think I fixed minimap issue. Will commit fix a bit later. Can you post the patch here, just to test it before you apply it to upstream?.. |
(0002485) Ivan (developer) 2012-05-17 22:48 |
Patch uploaded. I've cut it from my own changes but it should be complete. |
(0002486) douggie_m (reporter) 2012-05-18 09:03 edited on: 2012-05-18 09:05 |
This does definitely look like another bug, not "minor" and not "sound, music, video": ---------------------------------------- $ ps -A | grep vcmiserver 2309 pts/4 00:00:01 vcmiserver ... (gdb) attach 2309 ... (gdb) c ... Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xf6eff450 (LWP 2500)] 0x0f7fdc48 in BattleInfo::setupBattle (tile=..., terrain=3, terType=11, armies=0x104285b8, heroes=0x104285c0, creatureBank=false, town=0x0) at BattleState.cpp:1753 1753 creatureBank ? commanderBank[i] : commanderField[i]); (gdb) bt #0 0x0f7fdc48 in BattleInfo::setupBattle (tile=..., terrain=3, terType=11, armies=0x104285b8, heroes=0x104285c0, creatureBank=false, town=0x0) at BattleState.cpp:1753 #1 0x0f90fc90 in CGameState::setupBattle (this=0x10840e80, tile=..., armies=0x104285b8, heroes=0x104285c0, creatureBank=false, town=0x0) at CGameState.cpp:787 0000002 0x10172a50 in CGameHandler::setupBattle (this=0x108408e0, tile=..., armies=0x104285b8, heroes=0x104285c0, creatureBank=false, town=0x0) at CGameHandler.cpp:1464 0000003 0x101697a4 in CGameHandler::startBattle(CArmedInstance const**, int3, CGHeroInstance const**, bool, boost::function<void (BattleResult*)>, CGTownInstance const*) (this=0x108408e0, armies=0x104285b8, tile=..., heroes=0x104285c0, creatureBank=false, cb=..., town=0x0) at CGameHandler.cpp:372 0000004 0x10295774 in boost::_mfi::mf6<void, CGameHandler, CArmedInstance const**, int3, CGHeroInstance const**, bool, boost::function<void (BattleResult*)>, CGTownInstance const*>::operator()(CGameHandler*, CArmedInstance const**, int3, CGHeroInstance const**, bool, boost::function<void (BattleResult*)>, CGTownInstance const*) const (this=0x10958bd4, p=0x108408e0, a1=0x104285b8, a2=..., a3=0x104285c0, a4=false, a5=..., a6=0x0) at /usr/include/boost/bind/mem_fn_template.hpp:732 0000005 0x10295334 in boost::_bi::list7<boost::_bi::value<CGameHandler*>, boost::_bi::value<CArmedInstance const**>, boost::_bi::value<int3>, boost::_bi::value<CGHeroInstance const**>, boost::_bi::value<bool>, boost::_bi::value<boost::function<void (BattleResult*)> >, boost::_bi::value<CGTownInstance const*> >::operator()<boost::_mfi::mf6<void, CGameHandler, CArmedInstance const**, int3, CGHeroInstance const**, bool, boost::function<void (BattleResult*)>, CGTownInstance const*>, boost::_bi::list0>(boost::_bi::type<void>, boost::_mfi::mf6<void, CGameHandler, CArmedInstance const**, int3, CGHeroInstance const**, bool, boost::function<void (BattleResult*)>, CGTownInstance const*>&, boost::_bi::list0&, int) (this=0x10958bdc, f=..., a=...) at /usr/include/boost/bind/bind.hpp:670 0000006 0x10295144 in boost::_bi::bind_t<void, boost::_mfi::mf6<void, CGameHandler, CArmedInstance const**, int3, CGHeroInstance const**, bool, boost::function<void (BattleResult*)>, CGTownInstance const*>, boost::_bi::list7<boost::_bi::value<CGameHandler*>, boost::_bi::value<CArmedInstance const**>, boost::_bi::value<int3>, boost::_bi::value<CGHeroInstance const**>, boost::_bi::value<bool>, boost::_bi::value<boost::function<void (BattleResult*)> >, boost::_bi::value<CGTownInstance const*> > >::operator()() (this=0x10958bd4) at /usr/include/boost/bind/bind_template.hpp:20 0000007 0x10292858 in boost::detail::thread_data<boost::_bi::bind_t<void, boost::_mfi::mf6<void, CGameHandler, CArmedInstance const**, int3, CGHeroInstance const**, bool, boost::function<void (BattleResult*)>, CGTownInstance const*>, boost::_bi::list7<boost::_bi::value<CGameHandler*>, boost::_bi::value<CArmedInstance const**>, boost::_bi::value<int3>, boost::_bi::value<CGHeroInstance const**>, boost::_bi::value<bool>, boost::_bi::value<boost::function<void (BattleResult*)> >, boost::_bi::value<CGTownInstance const*> > > >::run() ( this=0x10958ad0) at /usr/include/boost/thread/detail/thread.hpp:62 0000008 0x0f25d40c in ?? () from /usr/lib/libboost_thread.so.1.49.0 0000009 0x0f21c7b0 in start_thread (arg=<optimized out>) at pthread_create.c:306 0000010 0x0ed3fb10 in clone () at ../sysdeps/unix/sysv/linux/powerpc/powerpc32/clone.S:123 |
(0002488) douggie_m (reporter) 2012-05-18 10:15 |
Oops, I suffered Debian Sid power to break everything: ---------------------------------------- Cannot establish connection! Retrying within 2 seconds Establishing connection... Found endpoints: 0: 127.0.0.1:3030 Trying connection to 127.0.0.1:3030 (0) Problem with connecting: system:101 Something went wrong... checking for error info system:101 ---------------------------------------- $ ping 127.0.0.1 connect: Network is unreachable ---------------------------------------- So, please, ignore the deleted comment and the last screenshot. Writing from OS X now (by the way, where's VCMI for OS X? ;) I dunno how and when I'll fix this no-networking-at-all issue. |
(0002489) Ivan (developer) 2012-05-18 10:29 |
VCMI for OS X? We don't have anybody with this OS but as far as I know it works. You need to compile it yourself though. One note - you'll need at least gcc-4.5. clang or earlier gcc versions won't work Looks like commanders issue. That also explains why it as not present in 0.88. Open new issue in Battles/Mechanics if you wish |
(0002490) Ivan (developer) 2012-05-18 10:55 |
Ok. I think i found it. You need to update configuration files: copy them (or create symlink) - files in /usr/local/share/vcmi/config should be the same as in /path/to/source/config |
(0002491) douggie_m (reporter) 2012-05-18 11:13 edited on: 2012-05-18 11:23 |
> Ok. I think i found it. You need to update configuration files If this is about vcmiserver's issue, I've already open a separate issue. http://bugs.vcmi.eu/view.php?id=960 [^] |
(0002493) Ivan (developer) 2012-05-18 17:37 |
Moving to resolved - minimap was fixed in rev 2688. |
(0002515) douggie_m (reporter) 2012-05-21 16:29 edited on: 2012-05-22 17:06 |
-- I do confirm the fix. ++ I confirmed the fix when I applied endian-minimap.patch to r2684. Fresh SVN (r2704) now shows greenish minimap, no magenta border now :( Screenshot will follow. |
(0002522) douggie_m (reporter) 2012-05-22 17:07 |
I confirmed the fix when I applied endian-minimap.patch to r2684. Fresh SVN (r2704) now shows greenish minimap. |
(0002525) Ivan (developer) 2012-05-22 17:26 |
I won't have time for VCMI for several days but I'll check what went wrong here as soon as I can. |
(0002526) douggie_m (reporter) 2012-05-22 17:42 edited on: 2012-05-22 17:43 |
By the way, if you'll look on Screenshot - 05212012 - 12:30:10 PM.png (it was a result of applying endian-minimap.patch to r2684), you'll not see colored towns and mines on minmap. In current SVN (r2704) they are visible, but the whole minimap is colored wrong, and it is in another "direction" (not blueish, but greenish). |
(0002550) Ivan (developer) 2012-05-25 11:58 |
For some reason red channel was set to zero. Check rev. 2709 - not sure what's causing the glitch so this is mostly guessing "what may be wrong". |
(0002552) majaczek (reporter) 2012-05-25 12:57 |
24bit color putter was accessed apparently to put unused/alfa field (I read the cod but I don't remember where it actually appear). That means it owerwrite next pixel first color - you need not to use alpha/unused channel in any non-32-bit color putter (maybe use static_assert() to make sure it is never used where "it doesn't exist" ?) |
(0002560) douggie_m (reporter) 2012-05-25 19:11 |
Well. It. Is. Okay. You. did. It. Great. RESOLVED FIXED P.S. Apparently, the next release version shall be numbered 1.0 or at least 0.9 (but not 0.89). |
(0002561) Ivan (developer) 2012-05-25 19:44 |
So it looks that I'm good with guessing. Moving to resolved. But why next version should be not 0.89? |
(0002562) douggie_m (reporter) 2012-05-25 19:47 |
> why next version should be not 0.89? Well, you did great work. That's why. Also, these commanders. By the way, will be any option to turn these "WoG" extensions off maybe? To not to get commanders on battle, for example. |
Issue History | |||
Date Modified | Username | Field | Change |
2012-05-16 08:23 | douggie_m | New Issue | |
2012-05-16 08:23 | douggie_m | File Added: Screenshot - 05162012 - 03:55:10 AM.png | |
2012-05-16 08:34 | douggie_m | Note Added: 0002445 | |
2012-05-16 08:42 | douggie_m | File Added: Screenshot - 05162012 - 04:32:46 AM.png | |
2012-05-16 12:15 | Ivan | Note Added: 0002447 | |
2012-05-16 12:15 | Ivan | Assigned To | => Ivan |
2012-05-16 12:15 | Ivan | Status | new => assigned |
2012-05-16 12:36 | Ivan | Note Edited: 0002447 | View Revisions |
2012-05-16 13:23 | douggie_m | Note Added: 0002449 | |
2012-05-16 13:49 | douggie_m | Note Edited: 0002449 | View Revisions |
2012-05-16 14:06 | douggie_m | Note Edited: 0002449 | View Revisions |
2012-05-16 14:59 | douggie_m | Note Added: 0002450 | |
2012-05-16 15:03 | douggie_m | File Added: Screenshot - 05162012 - 10:55:00 AM.png | |
2012-05-16 15:06 | Ivan | Note Added: 0002451 | |
2012-05-16 15:07 | Ivan | Note Edited: 0002451 | View Revisions |
2012-05-16 15:15 | douggie_m | Note Added: 0002452 | |
2012-05-16 15:23 | Ivan | Note Added: 0002453 | |
2012-05-16 15:34 | douggie_m | Note Added: 0002454 | |
2012-05-16 15:40 | douggie_m | Note Edited: 0002454 | View Revisions |
2012-05-16 15:49 | Ivan | Note Added: 0002455 | |
2012-05-16 15:51 | douggie_m | Note Edited: 0002454 | View Revisions |
2012-05-16 15:51 | Ivan | Note Edited: 0002455 | View Revisions |
2012-05-16 15:53 | douggie_m | Note Added: 0002456 | |
2012-05-16 15:54 | douggie_m | Note Edited: 0002456 | View Revisions |
2012-05-16 15:56 | Ivan | Note Edited: 0002455 | View Revisions |
2012-05-16 15:58 | Ivan | Note Added: 0002457 | |
2012-05-16 15:59 | douggie_m | Note Edited: 0002456 | View Revisions |
2012-05-16 16:01 | Ivan | Note Edited: 0002455 | View Revisions |
2012-05-16 16:02 | Ivan | Note Edited: 0002457 | View Revisions |
2012-05-16 16:02 | douggie_m | Note Added: 0002458 | |
2012-05-16 16:02 | douggie_m | Note Edited: 0002458 | View Revisions |
2012-05-16 16:05 | douggie_m | Note Edited: 0002458 | View Revisions |
2012-05-16 16:10 | douggie_m | Note Added: 0002459 | |
2012-05-16 16:17 | douggie_m | File Added: Screenshot - 05162012 - 12:09:17 PM.png | |
2012-05-16 16:34 | Ivan | Note Added: 0002460 | |
2012-05-16 16:44 | Ivan | Note Added: 0002461 | |
2012-05-16 16:48 | douggie_m | Note Added: 0002462 | |
2012-05-16 17:00 | Ivan | Note Added: 0002463 | |
2012-05-16 17:22 | Ivan | Note Added: 0002464 | |
2012-05-16 17:31 | Ivan | Note Edited: 0002464 | View Revisions |
2012-05-16 19:27 | douggie_m | Note Added: 0002465 | |
2012-05-16 19:28 | douggie_m | Note Edited: 0002465 | View Revisions |
2012-05-16 19:35 | douggie_m | Note Edited: 0002465 | View Revisions |
2012-05-16 19:48 | douggie_m | Note Added: 0002466 | |
2012-05-16 19:49 | douggie_m | File Added: Screenshot - 05162012 - 03:44:29 PM.png | |
2012-05-16 19:56 | douggie_m | Note Edited: 0002466 | View Revisions |
2012-05-16 19:59 | douggie_m | File Added: Screenshot - 05162012 - 03:57:26 PM.png | |
2012-05-16 20:04 | douggie_m | Note Edited: 0002466 | View Revisions |
2012-05-16 20:06 | douggie_m | Note Edited: 0002466 | View Revisions |
2012-05-16 20:07 | douggie_m | Note Edited: 0002466 | View Revisions |
2012-05-16 20:12 | douggie_m | Note Edited: 0002466 | View Revisions |
2012-05-16 20:14 | Ivan | Note Added: 0002467 | |
2012-05-16 20:21 | douggie_m | Note Added: 0002468 | |
2012-05-16 20:30 | douggie_m | Note Added: 0002469 | |
2012-05-16 20:36 | douggie_m | Note Added: 0002470 | |
2012-05-16 20:38 | douggie_m | File Added: Screenshot - 05162012 - 04:36:22 PM.png | |
2012-05-16 20:53 | douggie_m | Note Edited: 0002470 | View Revisions |
2012-05-16 21:17 | douggie_m | Note Added: 0002471 | |
2012-05-16 21:18 | douggie_m | File Added: endianless_patch.patch | |
2012-05-16 21:29 | douggie_m | Note Edited: 0002471 | View Revisions |
2012-05-16 21:29 | douggie_m | File Added: endianless_patch_corrected.patch | |
2012-05-16 21:51 | douggie_m | File Added: Screenshot - 05162012 - 05:49:19 PM.png | |
2012-05-16 21:52 | douggie_m | Note Edited: 0002471 | View Revisions |
2012-05-16 21:56 | douggie_m | Note Added: 0002472 | |
2012-05-16 22:20 | douggie_m | Note Added: 0002473 | |
2012-05-16 22:34 | douggie_m | Note Edited: 0002473 | View Revisions |
2012-05-16 22:39 | douggie_m | Note Edited: 0002473 | View Revisions |
2012-05-16 22:47 | douggie_m | Note Deleted: 0002472 | |
2012-05-16 23:01 | douggie_m | Note Edited: 0002473 | View Revisions |
2012-05-17 10:48 | Ivan | Note Added: 0002474 | |
2012-05-17 19:08 | douggie_m | Note Added: 0002478 | |
2012-05-17 19:36 | douggie_m | Note Edited: 0002478 | View Revisions |
2012-05-17 19:38 | douggie_m | File Added: Screenshot - 05172012 - 03:35:32 PM.png | |
2012-05-17 19:39 | douggie_m | Note Edited: 0002478 | View Revisions |
2012-05-17 19:42 | douggie_m | Note Edited: 0002478 | View Revisions |
2012-05-17 20:22 | douggie_m | Note Added: 0002479 | |
2012-05-17 20:50 | Ivan | Note Added: 0002480 | |
2012-05-17 21:19 | douggie_m | Note Added: 0002481 | |
2012-05-17 21:19 | douggie_m | Note Edited: 0002473 | View Revisions |
2012-05-17 21:35 | Ivan | Note Added: 0002482 | |
2012-05-17 21:52 | douggie_m | Note Added: 0002483 | |
2012-05-17 21:57 | douggie_m | Note Added: 0002484 | |
2012-05-17 22:00 | douggie_m | Note Edited: 0002484 | View Revisions |
2012-05-17 22:48 | Ivan | File Added: endian-minimap.patch | |
2012-05-17 22:48 | Ivan | Note Added: 0002485 | |
2012-05-18 08:51 | douggie_m | Note Edited: 0002478 | View Revisions |
2012-05-18 09:03 | douggie_m | Note Added: 0002486 | |
2012-05-18 09:05 | douggie_m | Note Edited: 0002486 | View Revisions |
2012-05-18 09:16 | douggie_m | Note Added: 0002487 | |
2012-05-18 09:17 | douggie_m | File Added: Screenshot - 05182012 - 05:15:18 AM.png | |
2012-05-18 09:26 | douggie_m | Note Edited: 0002487 | View Revisions |
2012-05-18 09:27 | douggie_m | Note Edited: 0002487 | View Revisions |
2012-05-18 09:51 | douggie_m | Note Deleted: 0002487 | |
2012-05-18 10:15 | douggie_m | Note Added: 0002488 | |
2012-05-18 10:29 | Ivan | Note Added: 0002489 | |
2012-05-18 10:55 | Ivan | Note Added: 0002490 | |
2012-05-18 11:13 | douggie_m | Note Added: 0002491 | |
2012-05-18 11:23 | douggie_m | Note Edited: 0002491 | View Revisions |
2012-05-18 17:37 | Ivan | Note Added: 0002493 | |
2012-05-18 17:37 | Ivan | Status | assigned => resolved |
2012-05-18 17:37 | Ivan | Fixed in Version | => 0.89 |
2012-05-18 17:37 | Ivan | Resolution | open => fixed |
2012-05-21 16:29 | douggie_m | Note Added: 0002515 | |
2012-05-21 16:33 | douggie_m | File Added: Screenshot - 05212012 - 12:30:10 PM.png | |
2012-05-22 17:06 | douggie_m | Note Edited: 0002515 | View Revisions |
2012-05-22 17:07 | douggie_m | Note Added: 0002522 | |
2012-05-22 17:07 | douggie_m | Status | resolved => feedback |
2012-05-22 17:07 | douggie_m | Resolution | fixed => reopened |
2012-05-22 17:09 | douggie_m | File Added: Screenshot - 05222012 - 01:02:36 PM.png | |
2012-05-22 17:26 | Ivan | Note Added: 0002525 | |
2012-05-22 17:42 | douggie_m | Note Added: 0002526 | |
2012-05-22 17:42 | douggie_m | Status | feedback => assigned |
2012-05-22 17:43 | douggie_m | Note Edited: 0002526 | View Revisions |
2012-05-25 11:58 | Ivan | Note Added: 0002550 | |
2012-05-25 12:57 | majaczek | Note Added: 0002552 | |
2012-05-25 19:11 | douggie_m | File Added: Screenshot - 05252012 - 03:03:15 PM.png | |
2012-05-25 19:11 | douggie_m | Note Added: 0002560 | |
2012-05-25 19:44 | Ivan | Note Added: 0002561 | |
2012-05-25 19:44 | Ivan | Status | assigned => resolved |
2012-05-25 19:44 | Ivan | Resolution | reopened => fixed |
2012-05-25 19:47 | douggie_m | Note Added: 0002562 | |
2014-05-30 17:41 | beegee | Status | resolved => closed |
Copyright © 2000 - 2024 MantisBT Team |