[00:04:44] --> Kirben has joined #nuvie
[00:06:07] <-- wjp has left IRC ("Zzzz...")
[00:30:02] <-- servus has left IRC (Read error: 110 (Connection timed out))
[03:30:49] <-- Kirben has left IRC ("System Meltdown")
[03:46:05] --> Kirben has joined #nuvie
[05:20:32] --> armav has joined #nuvie
[05:20:41] <-- armav has left IRC (Client Quit)
[07:21:29] <-- SB-X has left IRC (Read error: 110 (Connection timed out))
[07:35:25] --> SB-X has joined #nuvie
[08:52:17] --> servus has joined #nuvie
[09:04:12] <servus> Hmm, I need yuv's help on deciphering his rendering system...
[09:09:26] <servus> Ah! Got it.
[09:36:39] <servus> http://18.104.22.168:8080/images/misc/Nuvie04.jpg (I hardcoded the positions of the brazier lights, mind you)
[09:52:47] --> luteijn has joined #nuvie
[09:52:57] <luteijn> looks great..
[10:02:51] <servus> Thanks:) -- Any idea where objects that might cast light are rendered, and how I might find if/how much light they cast?
[10:06:54] <luteijn> Haven't looked at that part; I would assume the 'casts light' and 'light level' are in the tileflags, as tileflags.txt refers to it
[10:09:50] <servus> But which function actually draws worldobjects? Oh, I'll poke around and see I s'pose :)
[10:12:53] <luteijn> hmm I think drawObjSuperBlock and drawObj in MapWindow.
[10:22:41] <luteijn> tile.flags2 & 0x3 seems to be the four bit light intensity
[10:24:27] <servus> Do different items have different intensities?
[10:24:38] <servus> I'm figuring out the 16 bit surface right now :)
[10:36:39] * servus goes Hmm.
[10:38:08] <luteijn> I've just hacked in something to show any tiles with light !=0 to stderr, seeing if it does something useful.. (probably will just spam me with debug data)
[10:39:01] <servus> OK, if you just point me to a file::line I can work in proper globetrotting, so to speak. *Grin*. I'm still being perplexed over this 16-bit buffer for now
[10:40:45] <luteijn> MapWindow.cpp (around line 436) do something with tile->flags2 & 3 to get the light intensity of the tile being done.
[10:42:33] <luteijn> looks like it will come by 3 times (as it draws lower tiels, normal tiles, toptiles, so whatch out you don't get too much light stacked
[10:43:34] <luteijn> Opening a moon gate twoo tiles above the avatar: found lightsource of intensity 3 at 5,3
[10:43:34] <servus> OK *Gives up on 16-bit alphablits for now...*
[10:43:44] <servus> Neato:)
[10:44:09] <luteijn> (spammed 3 times each update, luckily nuvie is low for me...)
[10:44:53] <servus> Can you post the code to get the intensity and x,y, if you've already done it...:)
[10:45:04] <luteijn> 5,3 is (x,y) from that function around found lightsource of intensity 3 at 5,3
[10:45:15] <luteijn> crap wrong paste buffer
[10:45:54] <luteijn> anywya, the x and y are already there, and light source int. is tile->flags2 & 0x3
[10:46:11] <luteijn> ls
[10:51:08] <servus> It works!
[10:51:42] <luteijn> hmm that function is called 3 times with three different flag combinations that have to be decided upon over and over again in a loop... I'd split the function up in 3 separate ones, to save on alu usage...
[10:51:50] <luteijn> Cool, screen shot?
[10:51:53] <servus> It all works :D
[10:52:06] <servus> It looks just like the one I just posted, but it's all done in a nonhackish way
[10:52:28] <luteijn> so the lightsources actually move as you walk around.
[10:52:43] <servus> Indeed they do :)
[10:53:10] <servus> radius = intensity * tile_size for now
[10:53:18] <luteijn> We'd have to check the original to find out how light stacks, I guess to find out if two weak lights equal a bright one...
[10:54:13] <servus> I'm very happy with the results:)
[10:54:32] <servus> Well, it does. I don't know about the original game though
[10:55:26] <servus> Now I only have two things on my plate : day/night cycle and making it work with 16bit
[10:55:33] <luteijn> hmm so if you stack enough torches you can have brighter than daylight, I guess the original doesn't stack, but just takes the brightest one..
[10:56:22] <luteijn> btw I use 16 bit so I would like that to work :)
[10:56:35] <servus> Any idea how it works? It seems to be some sort of system palette that is referenced...
[10:57:04] <servus> If I pixels[j]-- on every pixel, the colours are entirely ruined, so it seems to be an unordered palette.
[10:58:52] <luteijn> HAven't looked at the actual putpixel type stuff actually, but Iguess there's some sort of palette. The original game ran at 8 bits, and did palette rotation animations, so I guess the palette wouldn't have had any colors left to play with.
[10:59:42] <luteijn> try adding/detracting increments of 0x100 ?
[11:00:21] <luteijn> or doesn't that make sense at all?
[11:00:21] <servus> Hmm, this stove isn't casting light, maybe it wasn't supposed to
[11:00:56] <servus> The palette rotation code doesn't reveal anything to me -- it doesn't modify colours, it just cycles that actual elements of the array
[11:01:24] <servus> Any way I can check the flags of something during runtime?
[11:01:53] <luteijn> I was just thinking to extend the look function to dump flags to stderr :)
[11:02:48] <servus> Ditto.
[11:04:15] <luteijn> hm mwhat is the name of the oven you're looking at? 'oven'?
[11:06:03] <servus> I just thought of something insane but maybe not too hard -- converting u6 maps to u7!!!
[11:06:30] <servus> stove at 115, 1aa, 0 Tile: 722
[11:07:22] <servus> Everything else works -- I assume it's supposed to be that way :P
[11:07:30] <servus> It's just that the stove has cycling fire in it
[11:08:07] <luteijn> hmm teleport prompt is in gargoyle..
[11:08:39] <servus> Down from Castle British, then the first house to the left after the intersection, SE of the museum, same screen nearly
[11:08:55] <servus> I don't know why I'm implying that you should look :)
[11:11:20] <luteijn> hmm the wall fireplaces seem to be intensity 3
[11:13:23] <servus> Everything seems to be.
[11:16:29] <luteijn> I guess you could write a short loop through all the tiles to check if any have different intensity values..
[11:18:29] <servus> Hmm, the stove actually does have an intensity
[11:18:32] <servus> It's just low (2)
[11:18:55] <servus> I guess I should step up the gamma ramp on my globes :)
[11:19:54] <servus> OK, I'm going to make that u6 -> u7 converter :)
[11:20:18] <-- SB-X has left IRC (Read error: 110 (Connection timed out))
[11:20:38] <servus> I know the u7 mapformats well (I made an u7 clone from scratch) and I guess I can learn u6's by studying code... It shouldn't be harder than referencing u6 tiles to u7 middlechunks and voila:)
[11:22:06] --> SB-X has joined #nuvie
[11:35:12] <luteijn> sounds interesting
[11:36:22] <servus> I have driven Darke barmy with the idea. *Evilgrin*
[11:41:00] <servus> By the way, the +- 0x100 idea did nothing good... Hmm... I should probably read some documentation *Gasp*
[11:56:34] <servus> The format is RGB565
[11:56:51] <servus> (Supposedly)
[11:58:29] * SB-X looks around.
[11:58:32] <SB-X> something going on in here?
[12:01:11] <luteijn> see the log ;)
[12:01:26] <servus> I made lighting work in U6, with help on the "what objects cast light?" from luteijn :: http://22.214.171.124:8080/images/misc/Nuvie04.jpg tada!
[12:02:23] <servus> I am apparently using what yuv calls a "generic 16-bit surface buffer", whatever that means. I don't seem to see any rhyme or reason to it
[12:03:39] * SB-X oooh aah's.
[12:04:28] <luteijn> oh, scroll->display_string("Location: \n",2); is just for testing if Gargoyle works, or has a deeper meaning?
[12:04:30] <SB-X> will it work in 16bit mode?
[12:04:34] <servus> Hmm, it seems to be RGB844
[12:04:41] <servus> SB-X: It will in about 5 minutes
[12:04:50] * SB-X !'s.
[12:04:51] <SB-X> k
[12:05:20] <SB-X> luteijn: the only place that i see that is in Event where it prompts you for teleport location
[12:05:31] <servus> (Maybe)
[12:05:40] <servus> I'm having strange trouble deciphering the 16-bit format.
[12:05:41] <luteijn> yeah, I noticed that it was in gargoyle so wondered why..
[12:05:55] <luteijn> endian issue?
[12:06:52] <servus> Nah, changing even one bit on each pixel seems to destroy the scene integrity
[12:07:02] <SB-X> on that picture the bottom orbs are too far down
[12:07:05] <SB-X> but im sure you know that
[12:07:26] <SB-X> or my eyes deceive me
[12:08:21] <servus> The picture is a hack -- it was taken before I made it work correctly.
[12:11:36] <SB-X> so you deceive me
[12:12:02] <servus> Not really, since the picture describes how the engine currently really works
[12:13:01] <servus> Here I thought I had this blinkin' surface format worked out =-/
[12:13:15] <SB-X> heh
[12:13:46] <SB-X> :\
[12:14:42] <servus> 0xF000 is pure red, 0x0F00 is pure green, 0x00FF is pure blue, but it's not so simple!
[12:22:08] <servus> Ah, got it to work in 16-bit.
[12:22:52] <servus> Neatoneato
[12:23:21] <luteijn> so what was the trick?
[12:23:43] <servus> I'll just post the code
[12:23:54] <servus> http://sourcepost.sytes.net/sourceview.aspx?source_id=8564
[12:24:41] <servus> It looks good though :D
[12:26:39] <servus> The 'problem' was that the palette tends to use absolute maximums or minimums of primary colours, so doing an unrestricted -1 or +1 caused funky results
[12:27:29] <-- servus has left IRC (Read error: 104 (Connection reset by peer))
[12:27:45] --> servus has joined #nuvie
[12:28:10] <servus> mIRC has a *very* annoying habit of deleting all the logs on a disconnect
[12:29:28] <servus> The only thing left is daytime/nighttime cycles.
[12:31:29] <servus> OK, 'night.
[12:31:51] <luteijn> sleep well..
[12:39:58] <SB-X> sounds good
[12:40:05] <SB-X> hey luteijn
[12:40:24] <SB-X> how did you work around the coords limit in TimedPartyMove::timed?
[12:41:14] <luteijn> you mean the must be in different plane?
[12:41:19] <SB-X> i think i fixed locally but havnt sent it in yet
[12:41:19] <SB-X> ya
[12:41:46] <luteijn> i just added some more ||-red checks, no idea of it breaks anything.
[12:42:06] <luteijn> > if(loc.z != target->z) //FIX for moongate teleport on the same plane.
[12:42:06] <SB-X> loc.x == target->x... ?
[12:42:12] <SB-X> ok
[12:42:15] <luteijn> < if(loc.z != target->z || loc.x != target->x || loc.y != target->y) //FIXED for moongate teleport on the same plane.
[12:42:28] <SB-X> i see
[12:42:33] <luteijn> hopefully the .z changes last, so shortcut evaluation works.
[12:43:05] <SB-X> theres also one at the bottom
[12:43:28] <SB-X> i added a new method to Actor to replace those with, "is_nearby(x,y,z)"
[12:43:45] <SB-X> it will check the area instead of just one tile
[12:44:09] <SB-X> but will have to test later
[12:44:47] <luteijn> we'd need some sort of timeout too
[12:45:10] <luteijn> I already had a problem in a dungeon where everyone just did a merry dance around the gate.
[12:45:29] <luteijn> never stepping quite in.
[12:46:13] <SB-X> it should be the number of members in the party
[12:46:34] <SB-X> and the party following will be a lot better
[13:38:34] <-- luteijn has left IRC ("BitchX: for distribution only with a new PC")
[13:40:07] <-- Kirben has left IRC ("System Meltdown")
[13:53:59] --> sbx has joined #nuvie
[13:56:55] <-- SB-X has left IRC (Read error: 113 (No route to host))
[15:54:45] --> wjp has joined #nuvie
[17:41:26] --- sbx is now known as SB-X
[19:10:30] <-- wjp has left IRC ("bbl")
[19:18:06] --> wjp has joined #nuvie
[22:51:13] <-- servus has left IRC (Read error: 104 (Connection reset by peer))