IRC logs for #opendune on OFTC at 2012-12-14
⏴ go to previous day
03:33:13 *** glx is now known as Guest1419
03:37:21 *** glx is now known as Guest1420
05:27:33 <lulzh3ad> could some provide a list of checksums for the datafiles ?
05:44:26 <lulzh3ad> src/string.c:128:4: warning: implicit declaration of function strdup
05:44:48 <lulzh3ad> that means you forgot to #define _GNU_SOURCE before including string.h
05:45:05 <lulzh3ad> that is bad, because:
05:45:19 <lulzh3ad> src/string.c:128:8: warning: assignment makes pointer from integer without a cast
05:45:51 <lulzh3ad> (implicit functions return int, not pointers, which is a Bad Thing on amd64
06:15:31 <lulzh3ad> hmm how is fullscreen toggled ?
06:15:41 <lulzh3ad> neither F11 nor alt-enter works
06:15:51 <lulzh3ad> and there is no reference to SDL_WM_ToggleFullScreen in the code
06:17:57 <Xaroth|Work> who said there was any?
06:18:28 <Xaroth|Work> the resolution is way to piss poor to put it on full screen for any 'recent' pc
06:18:38 <Xaroth|Work> recent being anything made in the past 10 years
06:19:18 <lulzh3ad> i dont quite understand what you want to say
06:19:42 <lulzh3ad> games with 320x240 are unplayable on my 24" screen
06:20:05 <lulzh3ad> the window is like 5x5cm
06:20:06 <Xaroth|Work> implement it, make a PR
06:20:30 <lulzh3ad> should be a matter of 5 min
06:49:34 <lulzh3ad> oh i forgot all keyboard shortcuts
06:49:42 <lulzh3ad> wasnt there a way to select multiple units ?
06:55:50 <lulzh3ad> nice to see nsz' name in README.txt
06:55:59 <lulzh3ad> he's a fellow musl libc developer
07:00:03 <lulzh3ad> Xaroth|Work, do you know how to select multiple units ?
07:00:15 <lulzh3ad> or can you point me to some manual.txt that describes it ?
07:12:52 <lulzh3ad> hmm it seems what you do in your video handling code is wrong
07:13:05 <lulzh3ad> the fallthrough from keydown to keyup in your switch
07:13:22 <lulzh3ad> when you enter text, for example in the highscore, you have to hit enter twice
07:14:00 <lulzh3ad> (also it made my fullscreen fix getting toggled twice, thats why i had to debug it, and spent 15 min instead of 5)
07:15:59 <lulzh3ad> also there is a "hanging note" isse in the midi playback
07:34:06 <lulzh3ad> *sigh* game locked up
07:34:13 <lulzh3ad> in the true meaning of the word
07:34:22 <lulzh3ad> the lock in video_update was held
07:35:28 <lulzh3ad> of course i had to kill it while fullscreen, that left with me with a 640x480 desktop behind
07:35:47 <lulzh3ad> lets rebuild with debug info...
07:37:12 <lulzh3ad> how can one use verbose build mode ?
07:37:23 <lulzh3ad> i.e. what one usually does with make V=1
07:40:20 <lulzh3ad> ah, you lock with an int.
07:40:40 <lulzh3ad> that's of course not threadsafe at all
07:40:46 <lulzh3ad> (yep SDL uses threads)
08:09:05 <lulzh3ad> hmm. everytime i feel like i want to play, i end up debugging.
08:49:08 <lulzh3ad> wow. using a signal handler for the timer is definitely not the way things should be
08:50:22 <lulzh3ad> 1) the signal handler code sees a new "environment", i.e. static variables have the values they had at the time it was installed
08:50:56 <lulzh3ad> 2) the signal handler interrupts the main execution in the middle of whatever it was trying to do
08:51:13 <lulzh3ad> so if the signal handler needs to acquire a lock it waits forever
08:52:25 <lulzh3ad> the timer code should either be a separate thread, or the usual SDL facilities used
08:52:44 <lulzh3ad> iirc you can make it so SDL_PollEvents generates timer events
10:20:27 *** Xaroth|Work has joined #openDune
10:20:27 *** ChanServ sets mode: +o Xaroth|Work
10:22:55 <lulzh3ad> *sigh* this code seems quite buggy
10:27:42 <lulzh3ad> ah, gui.c also uses non-threadsafe locks
10:33:10 *** Xaroth|Work has joined #openDune
10:33:10 *** oxygen.oftc.net sets mode: +o Xaroth|Work
10:33:11 *** ChanServ sets mode: +v Xaroth|Work
11:12:41 <lulzh3ad> hmm, maybe a bad idea to use a thread at all, there are race conditions everywhere
11:13:01 <lulzh3ad> the asynchronous timer concept seems broken
11:13:24 <lulzh3ad> i guess it would be better if the timer logic was managed by the main loop
12:49:55 <TrueBrain> lulzh3ad: you say what now? Signals are not forks ... they operate in the same env .. OpenDUNE is a fine example of that, else things would go horribly wrong all the time ;)
12:50:25 <TrueBrain> and in relation to your 2), that is _exactly_ the idea yes ;)
12:50:44 <TrueBrain> threading in its current state is not an option, due to how Dune2 is written
12:50:53 <TrueBrain> same for putting a timer in the main loop, as there is no main loop
12:51:31 <TrueBrain> Dune2 (and by proxy, OpenDUNE) says: hello to 1995 ;)
12:52:17 <lulzh3ad> it was an overwritten variable (my lock var became 0 after the signal handler launched, because i forgot to clean a lock = false; statement)
12:53:08 <TrueBrain> the deadlock is between your X11 driver and your ALSA driver btw, and it is a bit of a pita
12:53:16 <TrueBrain> X11 randomly runs mallocs, for no clear and good reason
12:53:38 <lulzh3ad> anyhow, with my thread fix the game is playable now
12:53:47 <lulzh3ad> it wasnt with the signal stuff
12:54:04 <TrueBrain> it seems to depend heavily on the system .. which is odd ..
12:54:51 <lulzh3ad> it seems using a thread is the way to go forward
12:54:54 <TrueBrain> anyway, all that is really needed, is a lock on ALSA or X11, so they are not called both in a reentrant way
12:55:02 <TrueBrain> no, not really .. lot of other issues arrise frm it
12:55:13 <lulzh3ad> however it needs quite some revising of global variable usage that can be used from both threads
12:55:30 <lulzh3ad> so one has to analyze which code paths can be run by the timer thread
12:55:38 <TrueBrain> exactly; short term it is not a solution. Long term, the signal should be migrated to a single main loop ... but that requires a lot of work
12:55:43 <lulzh3ad> e.g, MTU callback, display() etc
12:56:15 <TrueBrain> anyway, easiest solution is to just disable music
12:56:19 <TrueBrain> insta-solves the deadlock ;)
12:56:55 <lulzh3ad> using a signal handler is completely bogus
12:57:28 <lulzh3ad> anything that calls malloc in between can crash
12:57:55 <lulzh3ad> a signal handler should not be more than a handful of codelines
12:58:09 <lulzh3ad> here, it calls all kinds of game functions
12:58:17 <TrueBrain> again, welcome to 1995
12:58:18 <lulzh3ad> some for sound, some for video
12:58:50 <lulzh3ad> does it work on windows ?
12:58:56 <lulzh3ad> it seems a thread is used there
13:00:35 <lulzh3ad> the dos game used interrupts i suppose ?
13:00:43 <TrueBrain> you suppose correctly
13:03:29 <lulzh3ad> mhm, at that time it was ok to it that way, since nothing outside the game could interfere
13:04:02 <lulzh3ad> do you plan to improve the game in some ways ?
13:04:13 <TrueBrain> what a silly question :P
13:04:16 <lulzh3ad> like selection mutliple units with a mouse-drag
13:04:28 <lulzh3ad> or allowing a bigger map area
13:04:37 <TrueBrain> who knows; first we have bugs to remove
13:04:49 <lulzh3ad> well, it's possible that you want to stay 100% like the original
13:04:50 <TrueBrain> there are also a lot of issues with simple ideas like the two you put out
13:04:58 <TrueBrain> bigger maps will be a HUGE Issue for game balance
13:05:26 <lulzh3ad> bug seeing a bigger area of them on the screen
13:05:30 <TrueBrain> so, atm, we try to keep the game as close to the original as possible, but removing the bugs and the stuff that really annoys gameplay
13:05:41 <TrueBrain> ah; that for sure is an option yes
13:06:49 <lulzh3ad> once you played games like c&c, handling the old user interface is kinda weird
13:08:11 <lulzh3ad> even though graphics and sound are nicer
13:08:47 <lulzh3ad> btw is it normal that the music output is kinda disturbed ?
13:09:36 <TrueBrain> would seem the signal handler is not called often enough
13:10:06 <lulzh3ad> you never experienced hanging notes ?
13:10:16 <TrueBrain> at least the ALSA up/downscaling worked very well on 3 different machines I have here
13:10:42 <TrueBrain> only at startup there is one, but that is vanilla ;)
13:10:52 <lulzh3ad> its also weird that one has to launch some sort of timidity server
13:11:00 <lulzh3ad> other games using it dont need that
13:11:32 <TrueBrain> lolz; do you realise you are judging first all the time, then later realise that there might be a reason? :)
13:12:09 <TrueBrain> anyway, we use timidity, as it handles MIDI fine; there is no need to implement any MIDI implementation in your own code when someone else did it better ;)
13:12:19 <lulzh3ad> hm ? i dont get what you mean
13:12:33 <lulzh3ad> no, other games using timidity dont need that you launch a server
13:12:45 <TrueBrain> "other games", such a broad term
13:12:51 <TrueBrain> let me name you one that does need it: OpenTTD
13:13:20 <lulzh3ad> at least with anonymous login
13:13:41 <TrueBrain> hmm, possible; Mantis has a hard time understanding a project is closed (e.g.: no new bugs), but does allow viewing
13:14:33 <lulzh3ad> APPLICATION ERROR #1201
13:14:33 <lulzh3ad> It is not allowed to use disposable e-mail addresses.
13:16:31 <lulzh3ad> APPLICATION ERROR #12
13:16:31 <lulzh3ad> This account is protected. You are not allowed to access this until the account protection is lifted.
13:17:34 <lulzh3ad> ok, apparently it is impossible to just LOOK at bug reports there.
13:18:18 <TrueBrain> weird; that should still work
13:18:40 <TrueBrain> I dunno ... I dislike Mantis :(
13:18:59 <TrueBrain> just please make no new bugs on it
13:19:14 <lulzh3ad> i prefer the github interface
13:19:29 <TrueBrain> they did a very nice job on it, yes
13:31:52 <lulzh3ad> as to the first pull request
13:32:06 <lulzh3ad> glibc defines strdup only when _GNU_SOURCE is set
13:32:15 <lulzh3ad> because it is a non-standard function
13:32:59 <TrueBrain> its weird that all my linux machines dont have that issues
13:33:01 <TrueBrain> it seems very local
13:33:06 <lulzh3ad> when it is an implicit decl (invalid C99 btw) the returned pointer gets truncated to int
13:33:11 <TrueBrain> that is why I would like to know which machines have the issue, and which dont
13:33:18 <TrueBrain> so I can trace the exact origin of the issue
13:33:34 <lulzh3ad> you dont get a warning about an implicit declaration ?
13:33:49 <TrueBrain> nope; OpenDUNE compiles clean on all machines, and all compilers I have and own
13:33:58 <TrueBrain> it is one of the requirements of OpenDUNE
13:34:13 <lulzh3ad> Feature Test Macro Requirements for glibc (see feature_test_macros(7)):
13:34:13 <lulzh3ad> _SVID_SOURCE || _BSD_SOURCE || _XOPEN_SOURCE >= 500 || _XOPEN_SOURCE && _XOPEN_SOURCE_EXTENDED
13:34:13 <lulzh3ad> || /* Since glibc 2.12: */ _POSIX_C_SOURCE >= 200809L
13:34:41 <TrueBrain> can you post that in the bug please? Tnx :)
13:42:35 <lulzh3ad> setting _GNU_SOURCE is totally standard
13:42:48 <lulzh3ad> nsz and i contribute to musl libc
13:43:37 <lulzh3ad> when you want features outside of the C standard, you need to set feature test macros
13:43:42 <lulzh3ad> it's as easy as that
13:44:12 <lulzh3ad> otherwise the headers would pollute the namespace of the program
13:44:44 <lulzh3ad> for example, it is perfectly fine for a C89 program to have his own strdup() and include string.h
13:45:21 <lulzh3ad> if string.h exposes that symbol by default, it would break that C program
13:46:16 <TrueBrain> something might be totally standard, it does not imply we should use it. Again, I try to keep OpenDUNE as close to ANSI-C (C89 if you will) as possible; sometimes that means we have to juggle a bit with some functions
13:46:22 <TrueBrain> strdup for sure is one of them
13:46:29 <TrueBrain> I just need to reproduce a problem before I can properly fix it
13:46:46 <lulzh3ad> the proper fix is in the pull request
13:47:02 <TrueBrain> that is your opinion :) I kindly disagree
13:47:20 <lulzh3ad> if rich felker, the author of musl libc would write a program that uses strdup, he would do exactly the same
13:47:28 <lulzh3ad> first line: #define _GNU_SOURCE
13:47:46 <TrueBrain> I am happy you have that standard; does it mean the whole world should follow it?
13:48:06 <lulzh3ad> it is not an opinion, it is a fact, and my knowledge stems from being involved in the musl libc project for nearly 2 years
13:48:16 <lulzh3ad> i ported about 100 applications to that libc
13:49:02 <lulzh3ad> there's nothing wrong with that line. which problem do you see ?
13:49:34 <lulzh3ad> the worst thing that can happen is a warning: _GNU_SOURCE redefined
13:49:44 <lulzh3ad> if somebody specifies it in his CFLAGS
13:50:01 <lulzh3ad> so to be 100% safe, make it
13:51:45 <TrueBrain> I am sure Rich Felker does it that way, nobody is disagreeing. Like I said, I am happy you guys use that as a standard for your work, and apply it to the many projects you ported
13:51:54 <TrueBrain> I just fail to see how that should force us to do the same?
13:52:06 <TrueBrain> I am not a big fan of: doing stuff because it works
13:52:18 <lulzh3ad> you use a function outside of the standard
13:52:25 <TrueBrain> I am more interested in why I dont get the warning, you do, and what differs
13:52:33 <lulzh3ad> and the only way to get it, is to use a feature test macro
13:52:50 <lulzh3ad> because you use glibc 2.12
13:53:06 <lulzh3ad> or your distro maintainer hardcoded _GNU_SOURCE into your features.h
13:53:14 <TrueBrain> so why does glibc 2.12 define that function with STRICT_ANSI on ...
13:53:36 <TrueBrain> as, it is not STRICT_ANSI
13:53:54 <lulzh3ad> glibc 2.12 only defines it iff _POSIX_C_SOURCE=200809L is set
13:54:13 <lulzh3ad> which is automatically set by features.h when you #define _GNU_SOURCE
13:54:14 <TrueBrain> how about strcasecmp?
13:54:40 <lulzh3ad> that was in POSIX 2001
13:54:44 <TrueBrain> and snprintf for that matter ..
13:54:47 <lulzh3ad> so it is included by default
13:55:09 <TrueBrain> fun fact btw, mingw is the only one that really follows STRICT_ANSI
13:55:23 <TrueBrain> where MSVC is the worst, and ignores all that totallllyyyyyyy
13:55:52 <TrueBrain> well, MSVC doesnt have snprintf, but that is another story
13:56:06 <lulzh3ad> they dont even support C99
13:56:35 <TrueBrain> the best part is vsnprintf, which is totally different than the POSIX version
13:56:41 <lulzh3ad> in fact, it is no C comiler
13:56:54 <lulzh3ad> it is some sort of non-conformant C++ compiler
13:57:40 <TrueBrain> hmm, I should see if TinyC still has work being done
13:58:01 <lulzh3ad> afaik pellesC is the best compiler available for windows
13:58:14 <TrueBrain> TinyC Compiler is not for Windows
13:58:17 <TrueBrain> it is just a lovely compiler
13:58:20 <TrueBrain> (ANSI-C only, but still)
13:58:46 <lulzh3ad> the curent tcc work goes on on repo.or.cz
13:59:00 <lulzh3ad> anyone can commit to it
13:59:14 <lulzh3ad> it is regularly cleaned up by some guy
14:02:32 <lulzh3ad> it is mostly C99 compatible by now
14:03:08 <lulzh3ad> however without no reasonable maintainership, tcc is kinda dead
14:03:31 <lulzh3ad> (the project was taken over by the author of the windows port after fabrice resigned)
14:05:07 <TrueBrain> anyway, to come back to strdup: OpenDUNE is ANSI-C, or tries to be as close as possible; there are only a handful of violations, and we want to keep it that way
14:05:21 <TrueBrain> a PR like yours as one huge drawback: it also allows many more non-ANSI-C shit
14:05:29 <TrueBrain> you won't notice that you use them, as you don't get an error
14:05:37 <lulzh3ad> strdup is already a violation, so add the feature test thats needed for it
14:05:56 <lulzh3ad> you can undef it after including string.h
14:05:58 <TrueBrain> so, I try to solve those a bit more clear, so we don't pull all features, just those that we all agree'd on are compatible enough to use
14:06:09 <lulzh3ad> then you only get a handful of str* symbols
14:06:30 <lulzh3ad> you dont use more features by enabling a feature test
14:06:37 <lulzh3ad> you just make some functions visible
14:07:00 <TrueBrain> let's try it again: I want to be in control which non-ANSI-C functions we use
14:07:04 <lulzh3ad> the only danger of enabling a feature test is to get a namespace clash
14:07:08 <TrueBrain> we do this by strictly allowing only a very small subset in
14:07:15 <TrueBrain> GNU_SOURCE is NOT a small subset
14:07:28 <TrueBrain> even only for string.h, it is not small
14:07:36 <lulzh3ad> it adds max 5 fucntions for string.h
14:07:48 <TrueBrain> which are 4 too many ;)
14:08:09 <lulzh3ad> there is no feature test for _GNU_SOURCE_BUT_ONLY_WITH_STRDUP
14:08:44 <lulzh3ad> <lulzh3ad> it adds max 5 fucntions for string.h
14:09:04 <lulzh3ad> it makes maximal 5 addiotional functions VISIBLE
14:09:14 <lulzh3ad> it doesnt link them to your binary oslt
14:09:32 <TrueBrain> lolz; if you re-read my argument you see I am not talking (At all) about what goes in the binary or not
14:09:59 <TrueBrain> I guess I just have to deal with strdup like we did with snprintf and strcasecmp .. hmm ..
14:10:14 <lulzh3ad> you added a forward decl ?
14:10:14 <TrueBrain> now I need a machine that throws that warning ...
14:10:52 <lulzh3ad> are you a windows developer ?
14:11:49 <TrueBrain> ha, found a machine, how lovely
14:15:58 <TrueBrain> you are clearly no windows developer, suggesting SDL for Windows; hihi :D
14:16:15 <TrueBrain> SDL in general is just piss .... when is 1.3 being released
14:17:49 <lulzh3ad> sdl 1.3 is not getting released
14:18:11 <lulzh3ad> 2.0 is what nobody uses yet, thankfully
14:18:31 <lulzh3ad> one lib less to install
14:18:45 <lulzh3ad> seems other games work fine with sdl on windows
14:18:56 <lulzh3ad> for example openBOR, of which i am a contributor
14:19:15 <lulzh3ad> dwarf fortress is also SDL and works fine on windoze
14:19:25 <TrueBrain> "fine" is such a relative word
14:19:32 <TrueBrain> I am happy OpenDUNE uses GDI
14:19:54 <TrueBrain> faster, less bloat, works
14:20:26 <lulzh3ad> faster than SDL? you're kidding
14:20:47 <lulzh3ad> only using directX directly would be faster
14:20:58 <TrueBrain> euh .. no .. GDI is still faster :P
14:21:23 <lulzh3ad> did you actually benchmark that ?
14:21:45 <lulzh3ad> iirc GDI is a primite API to render onto a window
14:22:09 <TrueBrain> for 2D direct draw, GDI won every single time
14:22:14 <lulzh3ad> while directX/openGL (and so also SDL) use hardware acceleration
14:22:40 <TrueBrain> remember OpenDUNE has no benefit from hardware ;)
14:23:07 <lulzh3ad> you're the one that mentioned "fast"
14:24:00 <lulzh3ad> it is of course faster to blit the image into the graphics hw directly than to use a software drawing API
14:24:37 <TrueBrain> you would be surprised how little the benefit is when you do pixel-by-pixel draw
15:32:06 <lulzh3ad> ah, you chose to use the idiot fix
15:32:25 <lulzh3ad> hardcoding a forward declaration is the worst possible fix
15:33:10 <lulzh3ad> because if the header doesnt have exactly the same prototype, this will cause a build error
15:33:39 <lulzh3ad> for example, if C14 comes out and they change the prototype to use a const *restrict char instead
15:33:55 <lulzh3ad> usually thats no problem if you include the header that defines it
15:35:47 <lulzh3ad> lol even worse, you use __const
15:36:03 <lulzh3ad> that's not available anywhere except glibc/gcc
15:37:44 <lulzh3ad> <sh4rm4> my suggested fix was to #define _GNU_SOURCE
15:37:44 <lulzh3ad> <nsz> that should not even compile :)
15:37:44 <lulzh3ad> <nsz> (comment is not closed)
15:37:52 <TrueBrain> @kban lulzh3ad there are no idiots, only people claiming others are.. An opinion is one thing, calling us idoits another. Byebye.
15:37:52 *** DorpsGek sets mode: +b *!~hgfhgfh@9YYAALAC4.tor-irc.dnsbl.oftc.net
15:37:53 *** lulzh3ad was kicked by DorpsGek (there are no idiots, only people claiming others are.. An opinion is one thing, calling us idoits another. Byebye.)
15:38:11 <TrueBrain> my patience ran out :D
15:38:42 *** DorpsGek sets mode: +o TrueBrain
15:38:59 *** TrueBrain sets mode: +b *!*@*.tor-irc.dnsbl.oftc.net
15:39:03 *** DorpsGek sets mode: -o TrueBrain
15:39:15 <TrueBrain> Xaroth: can we please leave tor banned? ;)
15:58:50 <TrueBrain> today made me wonder: does mingw already have a workable 64bit target that you know?
16:01:32 <TrueBrain> did you happen to try it (for OpenDUNE or OpenTTD)?
16:01:34 <glx> but I never really tried it
16:04:12 <TrueBrain> lets see ... which file to download .....
16:21:53 <glx> seems it's not as easy to use as normal mingw
16:22:02 <TrueBrain> yeah, I am having the same issue ..
16:22:06 <TrueBrain> well, was worth a try :D
16:25:32 <TrueBrain> oeh, the -bin file works, on linux
16:25:38 <TrueBrain> as a jail-like thingy
16:27:01 <TrueBrain> WSAFileHeader assert-compile fails :(
16:30:45 <TrueBrain> a few more warnings .. but overall I am surprised
16:32:27 <TrueBrain> linking fails ... CreateCompatibleDC and friends
16:33:26 <TrueBrain> well, we never tried crosscompiling, so I guess it makes sense
16:34:24 <glx> it's explained in "Setting up Windows own (SYSTEM) libraries" section of the mingw64_how_to page I linked
16:35:26 <glx> "and accordingly to this, the GCC linker will always fail when some system DLL is required, simply because it will inexorably found the corresponding 32 bit DLL instead ...
16:35:26 <glx> obviously not at compatible with a 64 bit executable."
16:36:46 <TrueBrain> okay ... well, that was a nice attempt :)
16:37:07 <glx> the solution seems to copy the dll from system32 to somewhere else
16:37:18 <TrueBrain> yeah, I Was trying it on a linux system, so ...
16:37:28 <TrueBrain> but owh well .. I Was mostly curious if it would compile; that it does
16:37:29 <glx> so windows don't autopick the wrong one
16:37:35 <TrueBrain> linking ... I leave for someone who really cares enough :D
16:38:57 <glx> for now I'll keep using MSVC for 64bit :)
16:39:25 <glx> I don't want to destroy my mingw/msys setup
16:39:57 <TrueBrain> hehe, I totally understand :)
16:40:12 <TrueBrain> also tried Mac OS X today again; still works fine
16:40:18 <glx> and now msvc express can target 64bit without "hack"
16:41:13 <TrueBrain> lolz; about time, and nice :)
16:41:35 <glx> 2005/2008 was a pain, 2010 just needed to use platform sdk, 2012 does it nativelly
16:41:59 <glx> indeed 2010 had 64bit compilers, it just missed the libs
16:43:29 <glx> but when opening a 2010 project in 2012 it will use 2010 toolset which doesn't work for 64bit obviously
16:44:22 <glx> and of course requires 2010 to be installed
17:46:52 <glx> hmm segfault when displaying HoF
17:47:16 <glx> is it due to the fact I use a HoF data from before a recent commit ?
18:21:21 <TrueBrain> didnt spent time fixing that ... baddddd ... :(
18:24:30 <glx> I tried adding padding data in my SAVEFAME.DAT but that failed
18:24:48 <glx> probably because endianess
18:27:43 <glx> hmm ok it was totally corrupted before I tried to fix it
21:04:22 <TrueBrain> Mantis is now officially closed :)
21:12:42 <glx> anyway my patch for VS2012 good idea or not ?
21:12:52 <TrueBrain> you are the MSVC expert :P
21:19:21 <glx> I like VS2012 (except it shouts in the menubar)
21:20:40 <glx> and finally only one express app is needed for all MS languages
21:48:39 <glx> hop removed menu shouting
23:46:14 <Tomaz> trying to make heads and tilas of my disassembly
23:46:29 <Tomaz> it seesm to want a struct the size of 22 bytes
23:46:50 <Tomaz> but all i can find info abous is SREGS, which is 8 bytes, and REGS which is 10 bytes
23:47:10 <Tomaz> so im,totally lost on wth to do..
23:47:19 <Tomaz> sicne i cant identify what these int386 does right now
23:49:29 <Tomaz> this doesnt happen to be something you might know a thing or 2 about?
23:51:41 <TrueBrain> about what exactly, sorry? :(
continue to next day ⏵