[00:07:54] --> Kirben has joined #exult
[00:07:55] --- ChanServ gives channel operator status to Kirben
[01:38:12] --> LordNAway has joined #exult
[01:46:10] <-- Lord_Nightmare has left IRC (Read error: 110 (Connection timed out))
[01:50:04] --- LordNAway is now known as Lord_Nightmare
[02:10:18] --> shazza has joined #exult
[02:27:45] --> Baastuul_ has joined #exult
[02:47:18] <-- Rottingbeef has left IRC (Read error: 110 (Connection timed out))
[06:21:18] <-- Marzo_away has left IRC ("Marzo vanishes suddenly.")
[07:03:24] --> pupnik has joined #exult
[07:19:53] <-- pupnik_ has left IRC (Read error: 101 (Network is unreachable))
[07:41:54] <-- Malignant_Manor has left IRC ("ChatZilla 0.9.84 [Firefox 3.0.8/2009032609]")
[08:35:05] --> shazza` has joined #exult
[08:39:09] <-- Baastuul_ has left IRC ("I, too, have lost a kingdom.")
[10:39:07] --> Fingolfin has joined #exult
[10:39:08] --- ChanServ gives channel operator status to Fingolfin
[10:39:28] <-- Colourless has left IRC (Read error: 110 (Connection timed out))
[10:45:43] --> Colourless has joined #Exult
[11:52:21] <-- ParuNexus has left IRC (Read error: 104 (Connection reset by peer))
[11:52:42] --> ParuNexus has joined #exult
[12:25:39] --> Marzo has joined #exult
[12:38:31] --- Marzo is now known as Marzo_away
[12:48:26] <Kirben> Anyone else find wud no longer compiles under mingw? getting weird mass of errors in mingw includes.
[12:48:32] --- Marzo_away is now known as Marzo
[12:48:45] <Marzo> Will check
[12:54:14] <Kirben> Strange errors - http://members.optusnet.com.au/scummvm/misc/error.txt
[12:55:15] <wjp> hm, interesting
[12:55:39] <Marzo> To say the least
[12:55:52] <wjp> in that command, can you replace the '-c' by a '-E' ?
[12:56:07] <wjp> that'll only preprocess the file
[12:56:52] <wjp> hopefully if you look for the line corresponding to windef.h line 238 there's some accidental #define-interference visible
[12:56:53] <Kirben> That seems to work fine.
[12:57:16] <wjp> wud.o now contains the preprocessed output
[12:57:25] <wjp> or actually s/output/input/
[12:58:59] <Kirben> The section of windef.h is:
[12:59:00] <Kirben> #ifndef XFree86Server
[12:59:01] <Kirben> #ifndef __OBJC__
[12:59:01] <Kirben> typedef WINBOOL BOOL;
[12:59:01] <Kirben> #else
[12:59:01] <Kirben> #define BOOL WINBOOL
[12:59:02] <Kirben> #endif
[12:59:05] <Kirben> typedef unsigned char BYTE; (line 238)
[12:59:08] <Kirben> #endif /* ndef XFree86Server */
[12:59:44] <wjp> can you see the corresponding bit in the preprocessed code?
[13:00:16] <wjp> (there might not be much left of it, except the typedef)
[13:01:25] <wjp> it may be findable by searching for windef.h in the line number debugging marks and then searching for 'typedef unsigned char'
[13:06:10] <Kirben> Not sure what exactly I'm looking for - http://members.optusnet.com.au/scummvm/misc/wud.o
[13:06:32] <Marzo> Did it work in the previous revision?
[13:08:05] <Kirben> No luck with previous revision (5682) either.
[13:08:59] <wjp> ah, gotta love C++ header files... *waits for pages and pages of STL headers to scroll by*
[13:09:04] <Marzo> Not quite what I meant, but helps anyway
[13:09:39] <wjp> the line "typedef unsigned char BYTE;" got turned into "typedef unsigned char 9;"
[13:09:51] <wjp> so there may be a '#define BYTE 9' somewhere, somehow
[13:10:12] <-- shazza` has left IRC ()
[13:10:28] <Marzo> Hm. in uctools.h
[13:10:59] <Marzo> (which hasn't been touched in years)
[13:11:18] <wjp> I guess we should either change that into a constant/enum, or shuffle the includes around so all system includes are before uctools.h
[13:14:41] <Marzo> Since the number of appearances of that particular case is small, replacing it is very easy
[13:17:24] <-- Colourless has left IRC ("casts improved invisibility")
[13:20:03] <Marzo> Changes committed to SVN; can you check if it fixes the issue?
[13:23:05] <Kirben> Unfortunately no difference.
[13:24:28] <Kirben> Wait, error changes.
[13:24:48] <Marzo> Well, that is it, I am converting it to an enum
[13:27:04] <Kirben> CLSID seems to be the conflict this time.
[13:29:37] <Kirben> Changing CLSID to CLSIDS works, and compiles this time.
[13:37:20] --- Marzo is now known as Marzo_away
[13:40:26] --- Marzo_away is now known as Marzo
[13:40:47] <Marzo> There; I switched it to enums instead of #defines
[13:51:57] --- Marzo is now known as Marzo_away
[13:57:01] <Kirben> Thanks, tools compile fine now.
[13:57:23] --- Marzo_away is now known as Marzo
[14:08:18] --> Rottingbeef has joined #exult
[14:16:55] --- Marzo is now known as Marzo_away
[14:28:38] <-- Kirben has left IRC (Read error: 60 (Operation timed out))
[15:30:19] --> ParuCodex has joined #exult
[15:48:42] <-- ParuNexus has left IRC (Read error: 110 (Connection timed out))
[16:29:58] --> Malignant_Manor has joined #exult
[16:50:46] <-- shazza has left IRC ()
[16:53:05] <-- Fingolfin has left IRC ()
[17:19:39] --> Fingolfin has joined #exult
[17:19:40] --- ChanServ gives channel operator status to Fingolfin
[17:51:53] --> ParuNexus has joined #exult
[17:51:53] <-- ParuCodex has left IRC (Read error: 104 (Connection reset by peer))
[17:53:43] --> Baastuul_ has joined #exult
[18:10:09] <-- Rottingbeef has left IRC (Read error: 113 (No route to host))
[18:34:50] --> Cahaan has joined #exult
[18:52:13] <-- Darke has left IRC (Read error: 104 (Connection reset by peer))
[18:58:45] <-- Fingolfin has left IRC (Read error: 104 (Connection reset by peer))
[18:59:18] --> Fingolfin has joined #exult
[18:59:18] --- ChanServ gives channel operator status to Fingolfin
[19:08:05] --> Darke has joined #exult
[19:37:23] <-- ettin has left IRC ("leaving")
[19:41:57] <Malignant_Manor> Is "if 0" debug or standard?
[19:42:05] --- Marzo_away is now known as Marzo
[19:42:25] <Marzo> "if 0" disables everything until the next #endif
[19:43:46] <Malignant_Manor> I have an if 0, then else, then endif
[19:44:21] <wjp> anything between then #if 0 and #else won't be compiled
[19:44:24] <Marzo> from the #if 0 to the else, everything will be ignored
[19:44:32] <Malignant_Manor> Ok, thanks
[19:45:34] <Malignant_Manor> I wonder why he used GL_LINEAR instead of GL_NEAREST for Exult 3D.
[19:45:52] <Marzo> Probably for performance
[19:47:05] <Malignant_Manor> I'll have to check the difference sometime. I'll just add -DUSE_GL_LINEAR to the Exult 3d build options.
[19:48:41] <Malignant_Manor> 6 files still left to merge before I can even begin compiling and some nasty ones are left.
[19:49:09] <Marzo> There are some more changes in the way, BTW; some that *might* improve performance
[19:49:50] <Marzo> (but I am still finishing them)
[19:50:16] <Malignant_Manor> Nice, else OpenGL would only be useful for Exult 3D. I read something on the forums a bit ago about a HQ OpenGL, a post by Moe.
[19:50:53] <Malignant_Manor> Of course, more work merging. :)
[19:51:08] <Marzo> Which is why I thought to warn you now :-)
[19:52:26] <Malignant_Manor> I can release up to the current revision and then try. It might be better that way. 16 files done if they compile nicely.
[19:53:23] <Malignant_Manor> With my knowledge, it is a bit hard to sort some things out. Lots of changes in the past few days.
[19:56:28] <Malignant_Manor> When I tried to use a video option gump button for Exult3D toggle, button delete crashed the game. Using a gameplay options button works fine for me.
[19:57:24] <pupnik> irc in the bathtub baby
[20:13:26] --- Marzo is now known as Marzo_away
[20:16:51] --> ettin has joined #exult
[21:01:34] <-- Fingolfin has left IRC (Read error: 104 (Connection reset by peer))
[21:01:52] --> Fingolfin has joined #exult
[21:01:52] --- ChanServ gives channel operator status to Fingolfin
[21:08:32] <Malignant_Manor> What's the difference between GL_CLAMP and GL_CLAMP_TO_EDGE?
[21:08:41] --- Marzo_away is now known as Marzo
[21:11:55] <wjp> I think GL_CLAMP blends with the background colour, while GL_CLAMP_TO_EDGE doesn't
[21:13:05] <Malignant_Manor> Thanks, I'm trying to understand the differences between the Exult 3D changes.
[21:18:51] --- Marzo is now known as Marzo_away
[22:01:35] <-- Cahaan has left IRC ()
[22:14:06] <Malignant_Manor> * Shakes fist at Marzo * How dare you keep fixing bugs. I think I need to start from scratch with the diff files.
[22:18:18] <-- Fingolfin has left IRC ()
[22:18:43] --- Marzo_away is now known as Marzo
[22:18:55] <Marzo> :-) Heh, I warned you :-)
[22:19:33] <Malignant_Manor> It wasn't just this patch. The other major overhaul screwed me over too.
[22:20:11] <Malignant_Manor> Doesn't help that I'm inexperienced and uneducated on this subject.
[22:20:40] <Marzo> Have you had a chance to test the performance of the changes to see if there is any difference?
[22:21:19] <Malignant_Manor> I just compiled it. I had to redownload svn in yet another folder.
[22:26:37] <Malignant_Manor> It might be slightly better performance. It's still maxing out with compiler and Mozilla open.
[22:31:12] <Malignant_Manor> Single core 2.4 GHz, 1 GB ram, XP Service Pack 3, NVIDIA GeForce FX 5500 256 MB
[22:31:30] --> Colourless has joined #Exult
[22:32:00] <Malignant_Manor> Hardware filters are off and it is set to performance over graphics.
[22:32:42] <Marzo> Are you using smooth scrolling?
[22:32:49] <Malignant_Manor> I took that off.
[22:33:48] <Malignant_Manor> 5 fps default resolution and x1 scaling (window)
[22:37:26] <Malignant_Manor> Even with audio disabled and fullscreen, mouse is sluggish. I don't have anything to monitor the cpu when fullscreen. I'm going to try it on a Vista x64(?) comp and see how it performs.
[22:39:40] <Marzo> That is mighty odd; using OpenGL 2x scaling on windowed mode and 10fps, my notemook (Turion X2 1,9GHz) with 512MG onboard video memory reaches about 26% CPU usage (about 50% of one core) while walking at high speed to Britain
[22:43:56] <Colourless> what operating system?
[22:44:06] <Marzo> Ubuntu x64
[22:44:42] <-- Malignant_Manor has left IRC (Read error: 60 (Operation timed out))
[22:45:17] <Colourless> thinking the wait function in exult may not be properly implemented
[22:45:45] <Colourless> can't remember exactly whats going on in it.
[22:45:57] <Colourless> i know that people were complaining about the midi drivers at one point
[22:46:43] <Colourless> being multithreaded i have a very short wait period so the play and stop commands from the game get detected quickly
[22:47:56] <Marzo> In this particular case, we were comparing notes on the performance with OpenGL
[22:48:04] --> Malignant_Manor has joined #exult
[22:48:23] <Marzo> I think that the midi problem has been fixed, hasn't it?
[22:48:28] <Colourless> probably has
[22:48:53] <Colourless> its been far too long since i did anything substantial in the code
[22:49:25] <Colourless> smooth scrolling isn't smoething i'd class as substantial purely because it didn't need *that* many code changes... and consequently that would probably why it breaks things
[22:49:43] <Marzo> FYI: Just testing with midi: the second core is indeed mostly idle
[22:53:08] <Colourless> could be 'vsync' related... graphics drivers sometimes wait in a loop for vsync to occur before returning to the program after the SwapBuffers (or equivilant on your opreating system) has been called
[22:53:37] <Marzo> Maybe
[22:53:41] <Colourless> can't imagine though it'd be the cause
[22:53:52] <Colourless> 50% of one core seems too high for that
[22:54:23] <Malignant_Manor> Without lerping and painting dirty cpu usage was around 20% or even less sometimes. (I think.)
[22:54:38] <Malignant_Manor> painting dirty instead of paint
[22:55:09] <Malignant_Manor> That is idle, but moving made it increase a lot but not max.
[22:55:24] <Colourless> uh..
[22:55:28] <Marzo> You mean in exult.cc:1199?
[22:56:05] <Marzo> (I based that on the code that was already there, BTW)
[22:56:29] <Marzo> (even ketp the comment about repainting "all each time")
[22:59:40] <Colourless> i wonder if the mouse cursor is causing trouble
[23:00:20] <Marzo> The mouse is part of the problem, definitely
[23:01:12] <Malignant_Manor> "ticks > last_repaint + 50" seems to take the same amount of cpu no matter how high I set the ticks
[23:01:23] <Malignant_Manor> When I tested it before.
[23:01:36] <Colourless> drawing the mouse reads back the contents of the screen before its painted
[23:01:54] <Colourless> line 141 of mouse.cc
[23:01:54] <Malignant_Manor> Without that there, mouse was crap, but it was using a lot less cpu.
[23:02:15] <Colourless> it *shouldn't* be needed for open gl
[23:02:17] <Marzo> It doesn't work with OpenGL because the OpenGL code forwards the shape drawing directly to the video buffer
[23:02:36] <Colourless> in opengl the drawing should be complete every time the screen changes
[23:03:11] <Colourless> the software rendered code does that because it doesn't want to repaint the entire screen when the mouse position or cursor changes
[23:04:55] <Colourless> Mouse::hide(), mouse.h:107 probably needs fixing for opengl too
[23:05:07] <Colourless> its where the backup is drawn back to the screen
[23:07:22] <Colourless> quite possibly Mouse::hide() and Mouse::show() are what are eating the CPU in opengl mode
[23:07:38] --> Kirben has joined #exult
[23:07:38] --- ChanServ gives channel operator status to Kirben
[23:08:17] <Marzo> I have my doubts; but I have to profile with valgrind just to be sure anyway
[23:10:20] <Marzo> Nope, disabling the mouse backup in OpenGL mode didn't make a difference in CPU usage
[23:10:49] <Colourless> hmm ok
[23:10:50] <Marzo> Strangely, standing around moving the mouse maxes out one of the cores, whereas walking around doesn't
[23:12:26] <Malignant_Manor> Quad core 2.5 GHZ, 6 GB ram, and pretty darn graphics card used around 40-45% cpu (shown in task manager)
[23:13:48] <Marzo> brb
[23:15:35] <Malignant_Manor> Dialog or having gumps open drastically reduces cpu usage.
[23:20:53] <Marzo> back
[23:21:22] <Marzo> Hm
[23:21:30] <Marzo> The rendering of flats is taking the most time
[23:29:26] <Marzo> Seems that the chunk cache is too small
[23:31:58] <Colourless> the chuck cache could be set to infinite and you probably wouldn't have a problem
[23:32:08] <Colourless> modern systems have *a lot* of memory
[23:32:27] <Colourless> hell, modern graphics cards have more memory than systems from a few years back
[23:33:08] <Malignant_Manor> Maybe a settable option to support lower end machines.
[23:33:45] <Marzo> I tried setting it to 30 (from 6) and CPU usage for the same mouse motion was cut in half
[23:34:23] <Malignant_Manor> How much ram usage?
[23:34:49] <Colourless> it was set tp 6...
[23:35:03] <Colourless> at higher resolutions that isn't enough enough for the entire screen
[23:35:13] <Marzo> Yep; six whole chunks were being cached in memory
[23:35:29] <Malignant_Manor> 6 chunks that is crazy.
[23:35:33] <Marzo> (there was sarcasm missing in that last sentence of mine, BTW)
[23:36:06] <Malignant_Manor> I figured you set it based on resolution.
[23:36:16] <Colourless> actually it may not enough be enough for 320x200
[23:36:24] <Marzo> There was some code to calculate it based on screen size; it should probably be moved to when the game window is resized to avoid repetition and it is fine
[23:37:02] <Colourless> it would be quite possible to have 9 chunks on screen at any given time if i'm right
[23:37:05] <Marzo> It isn't; in a 320x200 screen, GDB continually breaked at a breakpoint I set for when the chunk had no rendered flats even if standing still
[23:37:19] <Marzo> (with 6 chunks, that is)
[23:38:12] <Colourless> IMO, i'd set the chunk cache to about 100
[23:38:24] <Marzo> That works too
[23:38:40] <Colourless> they are 128x128 pixel, 16384 bytes each. so 100 chucks is 1.5mb
[23:38:45] <Colourless> give or take
[23:39:35] <Marzo> This cache is for whole chunks, not tiles
[23:39:43] <Marzo> (and tiles are 64x64 pixels)
[23:40:25] <Colourless> tiles are 8x8
[23:40:30] <Marzo> But the math cames out right in any case
[23:40:40] <Marzo> Yes, that is what I meant (sorry)
[23:40:40] <Colourless> 16 tiles per chunk
[23:40:57] <Colourless> chucks are (16 * 8) * (16 * 8)
[23:41:04] <Marzo> Yep, I just realized you are right; sorry for that
[23:41:27] <Marzo> (I started from 16x16 tiles, each tile being 64 pixels)
[23:41:35] <Colourless> if only... if only
[23:41:40] <Marzo> Well, setting cache to 100
[23:41:41] <Colourless> exult would look *really* nice
[23:45:26] <Marzo> Here is the result: after walking from just outside of Trinsic to Britain and back, the CPU usage of one core peaked at 70% with music, lots of NPCs and lots of SFX and animation
[23:45:38] <Marzo> Memory is at 32.4MiB
[23:46:00] <pupnik> exult is just fast enough on nokia n810
[23:46:42] <Marzo> (this is performance with OpenGL scaler, not general performance)
[23:46:43] <pupnik> if you slow it down, please try to IFDEF it
[23:46:46] <pupnik> ok
[23:47:21] <pupnik> next nokia will have GL ;)
[23:48:41] <Malignant_Manor> Well, They are working on making it much faster.
[23:49:58] <Malignant_Manor> Memory usage is still pretty nice. It is hard to tell exact amount since Exult gains memory the further you go.
[23:51:07] <Marzo> The peak I got in my wanderings was just under 50MB, with sounds, music, voice, weather, chunks and some gumps in the mix
[23:51:44] <Colourless> ow, Paint_image kind of sucks as far as functions go
[23:52:12] <Colourless> uh
[23:52:15] <Colourless> never mind
[23:52:20] <Marzo> ?
[23:52:20] <Colourless> not reading it properly
[23:53:07] <Marzo> FYI: Most of the OpenGL code I left untouched, as I do not have much experience with it
[23:53:38] <Colourless> just looking to see if there is any major performance mistakes in the code
[23:53:49] <Colourless> helps if i read the code properly
[23:55:08] <Colourless> one thing at the moment, that may need to be changed for some limited memory devices if they want to use opengl, is there doesn't seem to be any limit to the number of shapes converted into GL_texshapes
[23:55:23] <Marzo> I think there aren't, indeed
[23:57:39] <Colourless> would be nice if palette rotations in gl mode could be made to work
[23:58:14] <Colourless> i know how to do it too
[23:58:17] <Marzo> You can have gl palette rotations?
[23:58:48] <Colourless> if the graphics card supporeted palettized textures its trivial, but fat chance you'll see that now days
[23:58:59] <Marzo> (I ask because I added a way to have palette rotations in gl mode; but it does that by regenerating the GL_texshapes of any shapes that have rotation)
[23:59:22] <Colourless> the alternative way is to use a pixel shader
[23:59:27] <Colourless> fragment shader i mean
[23:59:37] <Colourless> (proper terminology)