#exult@irc.freenode.net logs for 14 Jul 2003 (GMT)

Archive Today Yesterday Tomorrow
Exult homepage

[01:01:02] --> Kirben has joined #exult
[01:01:02] --- ChanServ gives channel operator status to Kirben
[02:33:04] --> ShadwChsr has joined #exult
[02:33:08] <ShadwChsr> hey :)
[02:36:08] <ShadwChsr> Anyone awaaake? <grin>
[03:49:17] <-- ShadwChsr has left IRC ()
[04:33:59] --> ShadwChsr has joined #exult
[06:47:34] --> olivieryk has joined #exult
[07:15:16] <-- olivieryk has left IRC (Connection reset by peer)
[07:15:19] --> olivieryk2 has joined #exult
[07:18:16] --> wjp has joined #exult
[07:18:17] --- ChanServ gives channel operator status to wjp
[07:29:54] <ShadwChsr> hey :)
[07:30:37] <wjp> hi
[07:31:31] <ShadwChsr> You're one of the people working on pentagram, correct?
[07:31:37] <wjp> yes
[07:32:08] <ShadwChsr> Got a question for you.. having trouble with an algorithm :)
[07:32:29] <ShadwChsr> I upgraded my terrain engine to support "heights", similar to U8
[07:32:49] <ShadwChsr> problem is, I can't figure out the algorithm for determining the tile the mouse is over (screen to tile coordinates)
[07:33:29] <wjp> the way it's usually done is by tracing the drawing in reverse order
[07:34:20] <ShadwChsr> Hmmmm
[07:34:36] <ShadwChsr> I've seen that done in a 3d engine, but not a 2d one
[07:35:22] <wjp> your game is 3d enough to require it, I think
[07:35:44] <wjp> since different tiles can take up the same space on screen
[07:36:29] <ShadwChsr> Well, I'm not sure how to do it efficiently.
[07:36:40] <ShadwChsr> For my objects, I went through the entire (ugh) object list, and cast a ray from the mouse into the game world, testing a collision with each object's bounding box
[07:36:41] <wjp> how often do you want to call it?
[07:37:18] <ShadwChsr> when it found a collision, it would check the actual sprite for a pixel hit. If it hit a translucent area, it kept processing the AABB/ray collision stack
[07:37:31] <ShadwChsr> problem is it had to process all the objects in the vector each time. Yuck ;P
[07:37:54] <ShadwChsr> Hmmmmmm
[07:37:59] <wjp> that's not necessarily a problem if you only run it for mouse clicks
[07:38:16] <wjp> you can easily check several thousand objects without noticing it, probably
[07:39:11] <ShadwChsr> Yeah...
[07:39:48] <ShadwChsr> I guess for each 'cell' of terrain i would need to store a bounding box as well, and test the bounding box against ray, just like the objects
[07:39:56] * wjp nods
[07:40:04] <ShadwChsr> thats a ton of data if you have a large map though
[07:40:24] <wjp> you could restrict it to items that are actually on screen
[07:41:02] <ShadwChsr> I meant actual memory-sizes, but maybe it doesn't matter these days, maybe back on the 386 with 2 megs of ram ;)
[07:41:27] <wjp> don't you need that data anyway for collision detection?
[07:41:53] <ShadwChsr> collision detection (right now) is done against objects
[07:41:57] <ShadwChsr> not terrain yet
[07:42:05] <wjp> so how does it determine at which height you're supposed to stand?
[07:42:26] <ShadwChsr> well, it doesn't, yet. :-) The terrain height code is in it's infancy
[07:42:30] <wjp> ah
[07:42:47] <ShadwChsr> But I imagine the 'standing' height couldn't use the bounding box or Z value of the tile anyhow, since it would be a slope
[07:44:09] <ShadwChsr> the slope's vector would define the collision, not a bounding box.
[07:44:30] <ShadwChsr> hmmmm
[07:44:55] <ShadwChsr> What about the algorithm to determine which tiles to draw?
[07:45:24] <ShadwChsr> That one has confused me too.... The best I could figure would be to take screen->tile coordinates for each of the 4 screen corners
[07:45:45] <ShadwChsr> I would then increase the bottom two corners quite a bit for compensation for high buildings, etc
[07:46:19] --- Eclair is now known as Mistress_Anime
[07:46:20] <ShadwChsr> but that means calling the screen->tile code once for every time the screen (player) moves
[07:46:31] <wjp> is that a problem?
[07:46:31] <ShadwChsr> I can cache the other 3 values as offsets
[07:46:43] <ShadwChsr> Well, if the algorithm is slow, it will make the screen jerky when the player walks
[07:46:57] <wjp> well, you can obviously cheat there :-)
[07:47:28] <wjp> like just taking a fixed area around the player
[07:48:28] <ShadwChsr> for (int i = player.position.x - 50; i < player.position.x + 50; ++i) type of thing? :)
[07:48:42] <wjp> something like that yes :-)
[07:48:55] <wjp> it's what u8/pentagram do
[07:48:59] <ShadwChsr> LOL why didn't I think of that??? :)
[07:49:16] <ShadwChsr> Well, what if the camera is detatched from the player
[07:49:24] <wjp> s/player/camera/, and done :-)
[07:49:29] <ShadwChsr> think of using a crystal ball or something ;)
[07:50:48] <ShadwChsr> What does exult do about the diamond shape?
[07:51:00] <wjp> diamond shape?
[07:51:22] <ShadwChsr> when you draw from xMin to xMax, yMin to yMax on the game's axis, you end up with many extra tiles drawn in the top-center, left-center, right-center, bottom-center areas
[07:51:32] <wjp> exult has a rectangular grid
[07:51:44] <ShadwChsr> oops, I meant pentagram, sorry :P
[07:52:14] <ShadwChsr> Do you just say heck with it, and process them anyways?
[07:52:21] <wjp> either live with it (you can easily avoid drawing those tiles later on when you notice they're outside of the screen), or take a diamond-shaped 'fixed area around the camera'
[07:52:21] <ShadwChsr> or do you have a fancy algorithm to get around that? :)
[07:52:58] <ShadwChsr> I think I'm just going to live with it ;)
[07:53:39] <ShadwChsr> It's easy enough to have a fixed-size offset from the viewport's (player's position) for rendering, but that only applies to the current chunk
[07:53:46] <ShadwChsr> (the terrain the player is standing on)
[07:54:05] <ShadwChsr> what if there is a "seam" on the display?
[07:54:22] <ShadwChsr> In other words, you need to render more than one chunk of terrain at a time
[07:54:36] <ShadwChsr> each chunk has a different X/Y coordinate space
[07:54:46] <wjp> hm, why? :-)
[07:55:03] <ShadwChsr> Expansion :-)
[07:55:09] --- Mistress_Anime is now known as animeloe
[07:55:35] <wjp> well, it doesn't fundamentally change anything
[07:55:42] <wjp> it just makes things a bit more complicated
[07:56:05] <ShadwChsr> A "WorldPosition" is defined (kind of) as " TerrainNode(int X, int Y), TerrainPosition(double X, double Y, double Z) "
[07:56:37] <wjp> double?
[07:56:42] <ShadwChsr> its not as bad as say, dungeon siege that has a truely infinite game world
[07:56:44] <ShadwChsr> yeah
[07:56:56] <ShadwChsr> each "cell" is an increment of one
[07:57:26] <ShadwChsr> if you imagine an object as a single pixel, and i want that in the middle of a tile, I can give it a coordinate like 3.5, 6.5
[07:57:41] <ShadwChsr> The entire coordinate space is fully 3D
[07:58:55] <ShadwChsr> It makes it easy to sort the renderer, do collision detection, and allow any entity to exist anywhere, not placed pefectly on a cell
[07:59:24] --- animeloe is now known as Sakura-chan
[07:59:41] <wjp> Sakura-chan: identity-crisis? :-)
[07:59:56] <Sakura-chan> no
[07:59:57] <ShadwChsr> Thats another reason I cant have 4 billion x 4 billion cells and just index them across the entire world, like UO does.... I will loose precision (baaaad thing ;-)
[08:00:04] <Sakura-chan> ident registration updtaes
[08:00:41] <wjp> u8 uses integer coordinates, with "cells" taking up 32x32
[08:00:47] <wjp> so it's fixed-point in a sense
[08:00:55] <ShadwChsr> The game uses TerrainNodes which are chunks of terrain. Each is given a position in the world, with is the "int x, int y". Makes it easy(er) to splice em together
[08:01:41] <ShadwChsr> What I need to do is determine which chunks are currently displayed on the screen, and which cells in them need to be rendered. Sorting them for rendering is easy
[08:02:05] <ShadwChsr> Right now I just have hacked code that adds the focusednode (the one the player is standing on) to the list of nodes to be rendered, and thats it
[08:02:29] <ShadwChsr> How does pentagram determine which chunks need to be rendered?
[08:02:44] <wjp> it takes a fixed number around the camera
[08:02:57] <wjp> (the entire screen plus a couple on all sides)
[08:03:07] <ShadwChsr> Ahhhh
[08:03:39] <ShadwChsr> I kind of painted myself into a corner, because in my engine the chunk/terrainnode size is only world-fixed, not application-fixed
[08:03:58] <ShadwChsr> meaning one world can have terrain nodes 20x20 in size, and another terrain nodes 400x400 in size
[08:04:36] <wjp> multiple worlds?
[08:04:44] <ShadwChsr> world=map
[08:04:47] <wjp> you can only have one world on-screen at a time? :-)
[08:05:00] <ShadwChsr> There can only be one on screen at a time
[08:05:11] <wjp> that shouldn't be a problem then
[08:05:21] <wjp> just that the 'fixed number of chunks' will become somewhat variable :-)
[08:05:38] <ShadwChsr> Because I can pre-calculate the # of chunks when the world is loaded, right? :-)
[08:05:54] <wjp> yeah
[08:06:02] <ShadwChsr> Why didn't I think of that, LOL
[08:06:36] <ShadwChsr> If the chunk/node sizes were small, I could just calculate the # of chunks and render all the cells in each chunk, instead of determining which cells to render
[08:06:51] <ShadwChsr> the problem is, if the map has large chunks, things could get slow(er)
[08:07:57] <wjp> what exactly would it mean to "render" a cell that's off-screen?
[08:08:43] <ShadwChsr> the renderterrain for loops would be larger....
[08:09:35] <ShadwChsr> each time it takes the integer i/j iterators and generates a 'TerrainCellPosition' object from it (very, very lightweight..)
[08:10:21] <ShadwChsr> (block=node=chunk for this conversation, btw) it then calls terrainBlock->getCell(terrainCellPosition)->draw(..);
[08:11:19] <wjp> the 'slowest' part is probably the extra things you need to sort
[08:11:40] <ShadwChsr> draw in turn converts from "world space" to "screen space" (3 floating point multiplications, 3 conversions to integers, 3 'double' variable allocations, one integer addition)
[08:11:43] <wjp> to avoid that you could do some rough clipping before adding items to the sort list
[08:11:56] <ShadwChsr> It also would load the tile's graphic
[08:12:02] <ShadwChsr> (if it wasn't loaded already)
[08:12:20] <ShadwChsr> So the biggest piece of code would be the coordinate conversion, I imagine
[08:12:46] <wjp> but you'll need to do that anyway to be able to accurately determine if it's on-screen
[08:13:12] <ShadwChsr> *nods
[08:13:24] <ShadwChsr> but if it wasn't even in the loop, wouldn't need to determine that :-)
[08:13:40] <wjp> but how would you determine if it was in the list?
[08:14:05] <ShadwChsr> not sure ;P I like the idea of just having a fixed render area and just rendering all the cells in each chunk
[08:14:15] <ShadwChsr> its simple, not 150% optimized, but does the job
[08:14:41] <wjp> how fast is your sorting algorithm?
[08:14:46] <ShadwChsr> You're right about the sorting though. That's another performance issue I have marked as // HACK: .... each time an entity changes position, it gets removed from the entity list for the chunk then re-added
[08:14:49] <ShadwChsr> the add function sorts it
[08:15:05] <wjp> hm, so it's O(n^2)?
[08:15:20] <ShadwChsr> I wouldnt really call it a sorting algorithm, lol.. it doesnt do a full resort, it just iterates through the list until it finds where it wants to go, then gets inserted
[08:15:30] <wjp> no binary search?
[08:15:37] <ShadwChsr> no
[08:15:39] <wjp> using a linked list?
[08:15:52] <ShadwChsr> std::vector, I believe
[08:16:14] <wjp> hm, inserting in that is really slow
[08:16:18] <wjp> brb
[08:19:13] <ShadwChsr> it gets REALLY nasty if i do what i'm envisioning doing one day... having "3d" particle systems with each particle given a coordinate ;-)
[08:19:22] <ShadwChsr> (swirling effects around objects, etc)
[08:19:36] <ShadwChsr> of course, then you have hundreds of entities changing position every frame :)
[08:19:57] <wjp> b
[08:20:07] <ShadwChsr> though, I may just keep it simple and leave them with one bounding box, one position, but it could never exist "over" something
[08:20:15] <ShadwChsr> (as in, swirling around a player ;-)
[08:20:22] <wjp> you'll really want to switch from vector to a list-like container
[08:20:40] <ShadwChsr> use an insert iterator, correct?
[08:20:45] <wjp> yes
[08:20:54] <wjp> inserting in a list is O(1), in a vector is O(n)
[08:21:03] <ShadwChsr> I may have already changed it but forgot.. to be honest I reengineered alot of the game, and I haven't re-integrated that code yet, so i cant really remember :)
[08:21:25] <ShadwChsr> <nods>
[08:21:32] <ShadwChsr> I don't think I need fast random access anyways
[08:21:43] <ShadwChsr> (if at all)
[08:22:01] <ShadwChsr> Becuase I'll never have any idea what entity # 56 is :-)
[08:22:10] <ShadwChsr> will always be using front->back iterators
[08:22:18] <wjp> using a vector just might be faster if you do sorting afterwards
[08:22:41] <wjp> depends a bit on the number of items and how fast a comparison operation is
[08:22:42] <ShadwChsr> Do you think that algorithm is what I should do? the remove/readdsorted to list for every position change?
[08:22:58] <ShadwChsr> hmmmm
[08:23:16] <wjp> it's probably quite fast if not too many objects change position
[08:23:19] <ShadwChsr> lets say, 300 items
[08:23:46] <ShadwChsr> 200 of which are static, position doesnt change
[08:24:20] <ShadwChsr> you would then have maybe 60 items that can move but wouldnt change much... objects on tables, etc.. and then say 40 characters
[08:24:35] <wjp> remove/re-add might just be fastest
[08:24:56] <ShadwChsr> but if i drop in/program a rain particle emitter and want the rain particles 3D (collision detection, draw "behind" buildings, etc).. I'm toast hehe
[08:25:01] <wjp> (as long as you use a list...)
[08:25:31] <ShadwChsr> then I would have about 80 (sudo)"entities" changing position every frame
[08:25:43] <wjp> sudo?
[08:25:52] <wjp> isn't that a linux admin tool? :-)
[08:25:56] <ShadwChsr> ;-)
[08:26:03] <wjp> pseudo?
[08:26:14] <ShadwChsr> Yeah thats it ;-)
[08:26:20] <wjp> why not experiment a bit to see how adding 80 moving objects affects speed?
[08:26:25] <ShadwChsr> I'm a linux sysadmin *and* a programmer <grin>
[08:26:40] <wjp> just add 80 objects at random positions and move them each frame
[08:26:42] <ShadwChsr> my spelling takes a beating as a result <grin>
[08:26:47] <wjp> ;-)
[08:27:17] <ShadwChsr> <nods> I guess I can always change the algorithm later if it doesn't work out. I just wanted to make sure you didn't say "my GOD.. don't do that!!!!!" :-)
[08:27:42] <wjp> the only thing I would currently say that about is removing from/inserting into a vector :-)
[08:27:50] <ShadwChsr> *nods
[08:28:20] <ShadwChsr> Whats my best bet for the mouse->tile thing?
[08:28:28] <ShadwChsr> I was envisioning it execting "on mouse move"
[08:28:36] <wjp> hm
[08:28:49] <wjp> do you need it to detect objects or only tiles?
[08:28:49] <ShadwChsr> for example, in the map editor you select the tile you want to paint, then move over the map, and it renders the selection where the mouse is as a preview
[08:29:17] <ShadwChsr> Only tiles
[08:29:38] <wjp> you should have the sort order of those tiles somewhere, right?
[08:29:41] <ShadwChsr> the object one would be seperate, and maybe have a third function that calls tile one after the object one if the object one didnt find anything
[08:29:54] <ShadwChsr> Tiles are always sorted, they're in an array :)
[08:30:02] <wjp> so tiles can't obscure objects?
[08:30:18] <wjp> loop over the tiles in reverse drawing order...?
[08:30:27] <ShadwChsr> never, tiles are the ground terrain... tiles can only obscure other tiles (in the case of a hill)
[08:30:41] <wjp> but what if an object is behind a hill?
[08:30:51] <wjp> or don't you allow slopes that steep?
[08:30:52] <ShadwChsr> ick
[08:31:26] <ShadwChsr> drat, that will make my object mouse-collision code reallllllllll nasty
[08:31:26] <ShadwChsr> :)
[08:31:39] <ShadwChsr> However, it doesnt affect the tile one ;P
[08:32:41] <ShadwChsr> blargh
[08:32:58] <ShadwChsr> I cant even use bounding boxes to test the mouse-tile collisions because tiles are sloped
[08:33:11] <ShadwChsr> well... nevermind hehe
[08:33:28] <ShadwChsr> I can still use them as long as I tested against the actual sprite as well if i got a positive bounding box hit
[08:33:35] <wjp> bounding as a first approximation will still work
[08:33:38] * wjp nods
[08:34:01] <ShadwChsr> it means looping through every cell/tile that could be rendered every time though
[08:35:26] <wjp> well, yes, but you need to consider each tile, unless you add an even coarser way than bounding boxes of what to consider
[08:36:02] <ShadwChsr> what does pentagram do
[08:36:03] <ShadwChsr> ?
[08:36:18] <wjp> consider all items in the drawing list
[08:36:54] <ShadwChsr> ohhhhhhhhhhhh drat
[08:36:55] <wjp> then a 2d bounding box check, then a shape/sprite check
[08:37:11] <ShadwChsr> Right now my code always renders terrain first... cells arent in a drawing list
[08:37:24] <ShadwChsr> which means i'll get render errors for occluded objects
[08:37:36] <ShadwChsr> Not good
[08:37:54] <ShadwChsr> I also don't have nice large terrain sprites like U8
[08:38:01] <ShadwChsr> mine are more like UO... small tiles
[08:38:10] <ShadwChsr> ugh
[08:38:52] <ShadwChsr> I wonder what I should do now ;-)
[08:39:12] <wjp> u8's terrain cells aren't that big
[08:39:27] <ShadwChsr> Does u8 dynamically stretch the tiles, or did they draw them already on every angle?
[08:39:33] <wjp> hm, or maybe I've just become used to the 640x480
[08:39:49] <wjp> there's no stretching/rotating involved
[08:39:55] <ShadwChsr> ahhh
[08:40:04] <wjp> bbl, coffee :-)
[08:45:39] <ShadwChsr> BTW - plot stopper bug in Exult
[08:46:08] <ShadwChsr> At the mad mage in serpent isle... you toss all the body parts & egg into the machine.. but.. no boyden
[08:46:48] <ShadwChsr> the madmage has dialog options to do with a succesfull experiment, as though he'd already given me the serpent jawbone... its weird
[08:47:12] <ShadwChsr> i used the hack mover to make sure no parts went behind the machine... i swear i put in the egg, head, torso, two legs and two arms
[08:47:34] <ShadwChsr> talk to you tomorrow..
[08:47:44] <-- ShadwChsr has left IRC ()
[09:05:38] <-- olivieryk2 has left IRC ()
[09:05:56] --> olivieryk has joined #exult
[09:55:44] --> Dominus has joined #exult
[09:55:48] --- ChanServ gives channel operator status to Dominus
[09:55:58] --- wjp is now known as wjp|work
[10:53:17] <-- Dominus has left IRC ("enough for now")
[10:54:47] <-- wjp|work has left IRC (vinge.freenode.net irc.freenode.net)
[10:55:00] --> wjp|work has joined #exult
[10:55:01] --- ChanServ removes channel operator status from wjp|work
[11:13:47] --- wjp|work is now known as wjp
[11:13:48] --- ChanServ gives channel operator status to wjp
[11:13:54] --- wjp is now known as wjp|work
[12:02:06] <-- olivieryk has left IRC ()
[13:23:37] --> Colourless has joined #Exult
[13:23:37] --- ChanServ gives channel operator status to Colourless
[13:23:59] <Colourless> hi
[14:13:57] --> gt2 has joined #exult
[15:00:14] <-- wjp|work has left IRC ("bbl")
[15:15:00] --> olivieryk has joined #exult
[15:18:17] --> wjp has joined #exult
[15:18:17] --- ChanServ gives channel operator status to wjp
[15:37:04] <-- gt2 has left IRC (Connection timed out)
[15:42:53] --> gt2 has joined #exult
[16:09:24] --> Dark-Star has joined #exult
[16:39:12] --> artaxerxes has joined #exult
[16:39:12] --- ChanServ gives channel operator status to artaxerxes
[16:39:17] <artaxerxes> hi all
[16:39:29] <artaxerxes> long time no see Kirben !
[16:39:31] <Colourless> hi
[16:40:00] <artaxerxes> Colourless: did you have a chance to read the log? I left a message for you on Thurday
[16:40:11] <artaxerxes> ?logs
[16:40:11] <exultbot> Logs are available at http://www.math.leidenuniv.nl/~wpalenst/exultlog.php
[16:40:29] <Colourless> thursday?
[16:40:36] * artaxerxes is checking there are msg for him
[16:40:39] <Colourless> i read the logs everyday
[16:42:24] <Colourless> your code... has many 'issues'
[16:42:34] <artaxerxes> sill? :-(
[16:42:57] <Colourless> when you are attempting to write a string of 6 chars, your buffer must be at least 7 bytes (6 chars + terminator)
[16:44:08] <Colourless> you are defining some structures like Node in 2 different files
[16:44:28] <Colourless> in clean up, as far as I can tell, you are killing all the nodes multiple times
[16:45:02] <Colourless> it will always crash for me when cleaning up the 'action table'
[16:45:21] <Colourless> cause it's attempting to do delete_list() on lists that have already been deleted
[16:45:44] <artaxerxes> that makes no sense!
[16:46:14] <artaxerxes> the code do a delete_list(action_table[i]) with i going from 0 to max_size
[16:46:26] <artaxerxes> it should be done only one time
[16:46:45] <Colourless> not true
[16:46:57] <Colourless> if you pass an invalid pointer to delete_list() things wont work
[16:47:02] <artaxerxes> and I have typdefs only in globals.h
[16:47:25] <Colourless> node is in globals.g and header.h
[16:47:40] <artaxerxes> header.h??? There is no header.h !! :-)
[16:47:54] <artaxerxes> you might have an older version
[16:48:18] <Colourless> ah, that is probably it
[16:48:27] <Colourless> anyway, about the delete_list stuff
[16:48:40] <Colourless> // clean up list holding handles
[16:48:44] <Colourless> if(hdl_list != NULL){
[16:48:44] <Colourless> delete_list(hdl_list);
[16:48:44] <Colourless> hdl_list = NULL;
[16:48:44] <Colourless> }
[16:48:48] <Colourless> that code frees all the node correct?
[16:49:05] <Colourless> if so, why attempt to free them again in the action table
[16:49:33] <artaxerxes> there are 2 lists. One for storing the handles and one found in action_table.
[16:49:48] <artaxerxes> actually, there are MANY lists.
[16:50:00] <artaxerxes> one for the handles and each cell of action_table has a list too
[16:51:09] <artaxerxes> I used the same structure for both types of lists
[16:51:12] <Colourless> ah, i think i probably know what the problem is
[16:51:24] * artaxerxes is all ears
[16:51:30] <Colourless> you are not setting the handle to 0
[16:51:37] <Colourless> in your new nodes
[16:51:44] <artaxerxes> ahh
[16:52:01] <artaxerxes> indeed
[16:52:08] <artaxerxes> it should be NULL actually
[16:52:58] <Colourless> here's my proted code (just delete header.h): http://www.users.on.net/triforce/smooth.zip and compiled http://www.users.on.net/triforce/smooth_win32.zip
[16:53:18] <Colourless> now, i made a 'change' to the way the global_static and global_vars are pass
[16:53:20] <artaxerxes> but it doesn't work, right?
[16:53:20] <Colourless> ed
[16:53:34] <Colourless> it works fine, just doesn't free when leaving
[16:54:01] <Colourless> i made it pass pointers to the structures while you were passing the structures themselves
[16:54:03] <artaxerxes> I know a prog should exit cleanly, but doesn't the OS cleans up after a dead prog?
[16:54:18] <Colourless> yeah it will clean up
[16:54:33] <artaxerxes> any reason why you chose that way?
[16:54:46] <artaxerxes> (less memory maybe)
[16:54:51] <Colourless> passing the structures is not recommended, as it can be expensive, and any changes the plugin makes to the data structure will not be reflected in the caller
[16:55:17] <artaxerxes> no plugin should alter the data though, but I see your point
[16:55:42] <Colourless> the other thing is, with the statics if the host program changes the data, the plugin won't know
[16:56:17] <artaxerxes> that's why I called them global_statics. They are set at the beginning and never touch later
[16:56:30] <artaxerxes> not even by main
[16:57:04] <Colourless> last thing, i needed to add a few changes to explicitly specify which functions needed to exported by the plugin, these use PLUGIN_EXPORT, which if #ifdef'd to nothing if you aren't using windows
[16:57:05] <artaxerxes> did you pass pointers to both structures in the plugins?
[16:57:15] <Colourless> yes
[16:57:41] <Colourless> i had to 'fix' randomize so it was correctly using the right function
[16:57:45] <artaxerxes> it won't hurt I guess, but I'd rather the plaugin writer not to be able to change what shouldn't be changed
[16:57:49] <Colourless> it's plugin_apply wasn't correct
[16:58:10] <artaxerxes> char [6] right?
[16:58:21] <Colourless> it wasn't expecting the global vars to be passed to it
[16:58:38] <Colourless> when doing c programming static means something different const
[16:58:49] <Colourless> global_statics doesn't imply that something never changes
[16:59:13] <artaxerxes> not even by name? ;-)
[16:59:41] <Colourless> if it were global_consts that would be different
[16:59:52] <artaxerxes> true!
[17:00:38] <Colourless> i think i also made a number of other 'house keeping' type things around the place, but i can't remember exactly what
[17:01:15] <artaxerxes> I'll get your code and integrate that in mine. Have you added the new_node->handle = NULL to create_node ?
[17:01:26] <Colourless> no i haven't done that
[17:01:30] <Colourless> you should add that
[17:01:35] <artaxerxes> sure
[17:01:45] <Colourless> then uncomment //delete_list(action_table[i]);
[17:01:50] <Colourless> in smooth.c
[17:02:15] <Colourless> it would probably be a really good idea if you typedef'd all your function pointer types
[17:02:38] --> Fingolfin has joined #exult
[17:02:38] --- ChanServ gives channel operator status to Fingolfin
[17:02:55] <artaxerxes> my function pointer types?
[17:03:05] <Colourless> something like
[17:03:24] <Fingolfin> hi
[17:03:26] <Colourless> typedef void (*plugin_apply)(colour_hex ret_col, glob_variables *g_variables); // for storing plugins' apply
[17:03:52] <Colourless> but with plugin_apply being something 'else
[17:03:58] <artaxerxes> what is the benefit of that?
[17:04:23] <Colourless> then when you want to use a function pointer to for the plugin_apply function you'd just use that type
[17:04:45] <Colourless> rather than having to specify all the args and return type everywhere
[17:04:52] <Colourless> itt will make the code much easier to maintain
[17:06:28] <Colourless> example:
[17:06:29] <Colourless> typedef void (*pfnPluginApply)(colour_hex ret_col, glob_variables *g_variables);
[17:06:29] <Colourless> typedef struct pacman {
[17:06:29] <Colourless> struct pacman *next;
[17:06:29] <Colourless> pfnPluginApply plugin_apply; // for storing plugins' apply
[17:06:30] <Colourless> libhandle_t handle; // for storing dlopens' handle
[17:06:31] <Colourless> } node;
[17:06:52] <artaxerxes> got it. True, it's much niver
[17:06:57] <artaxerxes> s/v/c
[17:07:26] <artaxerxes> hi Fingolfin
[17:08:25] <Colourless> when you package your code, keep the .sln and .vcproj files
[17:08:40] <Colourless> they are the msvc projects
[17:08:54] <artaxerxes> k
[17:09:01] <Colourless> of course i should probably just make nmake makefile for msvc
[17:20:19] <artaxerxes> just finished diff'ing both code repositories. There's not that much of change after all!
[17:20:50] <Colourless> there wouldn't be
[17:20:55] <Colourless> i didn't do much
[17:21:19] <Colourless> but it took me a 'long' time to find the few problems that were causing it to crash
[17:21:47] <artaxerxes> thx for your help!
[17:22:12] <artaxerxes> Ram dragon's gonna be happy!
[17:24:37] <Colourless> funny thing. the 6 vs 7 byte colour problem was a buffer overrun....
[17:25:07] <Colourless> and msvc actually detected the buffer that overran :-)
[17:25:31] <Colourless> and the Buffer Security Check option wasn't enabled :-)
[17:26:18] <Colourless> i'm guessing they have 'improved' debugging for arrays on the stack by default
[17:27:06] <Colourless> abd the Buffer Security Check may be something more advanced
[17:27:24] * Colourless turns on Buffer Security Check in pentagram
[17:28:00] <Colourless> not that we use many arrays in pentagarm
[17:28:38] <Colourless> hmm... compiling is 'real' slow
[17:28:51] <Colourless> slower than gcc slow ;-)
[17:30:53] <Colourless> wow finally linking
[17:30:57] <wjp> oi! ;-)
[17:31:37] <artaxerxes> Colourless: you use gcc?
[17:31:44] <Colourless> no :-)
[17:31:47] <Colourless> i use msvc
[17:32:11] <artaxerxes> 'cause you seemed so intimate with gcc's principal attribute!
[17:32:11] <Colourless> i 'used' to use gcc with exult
[17:32:44] <artaxerxes> cygwin or mingw ?
[17:33:01] <Colourless> mingw
[17:38:16] <artaxerxes> in plugin.c, you return 0 if there is no error with GetLastError(), but the return type should be char * and not int.
[17:38:44] <Colourless> NULL = 0
[17:38:59] <wjp> 0 casts to any pointer type
[17:39:24] <artaxerxes> I've always though NULL = (void *)0 or sth like that
[17:39:46] <artaxerxes> wjp: I didn't know that!
[17:40:23] <wjp> it's recommended to use 0 instead of NULL in C++
[17:41:06] <Colourless> however most C++ compilers will
[17:41:08] <Colourless> #define NULL 0
[17:41:10] <Colourless> instead of
[17:41:12] <Colourless> #define NULL (void*)0
[17:41:18] <wjp> bbl, dinner
[17:41:27] <Fingolfin> in fact using NULL in C++ is not recommended
[17:41:31] <Fingolfin> one should use just 0
[17:41:36] <wjp> Fingolfin: that's what I just said ;-)
[17:41:42] <Fingolfin> oops yeah I just saw it, sorry =)
[17:41:50] <Fingolfin> only read the two last lines
[17:41:50] <wjp> np ;-)
[17:41:53] <wjp> *really gone now*
[17:42:04] <Fingolfin> so, yeah, just listen to wjp, he's always right anyway (unless he's wrong)
[17:43:01] <artaxerxes> Fingolfin: I saw your nick in linuxtoday on thursday in a talkback. Was it you?
[17:43:20] <Fingolfin> what is linuxtoday?
[17:43:25] <Fingolfin> (-> probably not)
[17:47:00] <artaxerxes> http://linuxtoday.com/news_story.php3?ltsn=2003-07-08-018-26-OP-BZ-DV-0005
[17:47:16] <artaxerxes> linuxtoday.com is a pretty good site for news about linux
[17:48:01] <artaxerxes> I guess it's just a coincidence. I found out too that there is a german dude who also uses Artaxerxes as a nick.
[17:48:16] <Fingolfin> hehe
[17:48:23] <artaxerxes> our nicks aren't uniq enough I guess
[17:48:30] <Fingolfin> you are french, aren't you?
[17:48:32] <artaxerxes> yup
[17:48:46] <Fingolfin> maybe that other Fingolfin is french... wouldn't that be a nice mixup? :-)
[17:48:53] <artaxerxes> sure! ;-)
[18:02:36] <wjp> Listening to Fingolfin is always a good idea too. You can trust him (unless you can't)
[18:02:59] <Fingolfin> indeed. as always willem is correct
[18:32:16] <olivieryk> artaxerxes you're french?
[18:33:12] <-- Kirben has left IRC (Read error: 54 (Connection reset by peer))
[18:44:47] <artaxerxes> yup
[18:46:45] <olivieryk> ša alors :)
[18:47:16] <artaxerxes> let's keep the chan english-only. start a /msg artaxerxes to speak french, d'acc?
[18:47:40] <olivieryk> lol
[18:47:44] <olivieryk> ok ok
[18:48:08] <olivieryk> going to watch some movie anyway, later.
[18:48:24] <artaxerxes> k
[19:24:07] <Colourless> i'm off
[19:24:07] <Colourless> cya
[19:24:14] <-- Colourless has left IRC ("casts invisibility")
[20:41:15] <-- olivieryk has left IRC ()
[21:14:09] <-- gt2 has left IRC (Connection timed out)
[21:22:42] --> Dominus has joined #exult
[21:22:42] --- ChanServ gives channel operator status to Dominus
[21:33:43] --> servus has joined #exult
[21:34:19] <Dominus> servus servus
[21:35:05] <servus> Yes?
[21:35:14] <Dominus> :-)
[21:35:27] <Dominus> Servus=Hello in german/austrian
[21:36:44] <Dominus> so I just said "hello servus"
[21:36:54] <servus> My dictionaries do not concur.
[21:36:58] <wjp> or hello slave, or slave servus, or servus hello, or... :-)
[21:37:22] <Dominus> screw the dictionaries, some things are not written there
[21:37:38] <wjp> I guess living in Austria gives you a bit of an advantage over dictionaries :-)
[21:37:56] <servus> Servi, Serdi, Serci?
[21:38:07] <Dominus> in Austria it is really common to greet people with "Servus"
[21:38:30] <servus> Have you people been deliberating over me in my absence?
[21:38:33] <Dominus> you can even say "good bye" with it :-)
[21:39:04] <Dominus> :-) not that I know of
[21:39:49] <Dominus> servus has a lot in common with the italian "ciao" (also used for hello and bye)
[21:41:17] <servus> *Continues working on his terrain engine...* It's quite good now, and 100% from scratch -- no copy and pasting for me :)
[21:41:47] <servus> How modular is the terrain-rendering part of Exul?
[21:42:20] <wjp> terrain rendering? it just draws a bunch of 8x8 squares
[21:43:05] <servus> That is terrain, and it is rendered(drawn.:)
[21:47:15] <-- wjp has left IRC ("Zzzz...")
[22:35:43] <-- Dominus has left IRC ("enough for now")
[22:50:05] <-- Dark-Star has left IRC ()
[22:53:55] <-- Sakura-chan has left IRC (Read error: 54 (Connection reset by peer))
[22:55:24] --> animeloe has joined #exult
[22:55:30] --- animeloe is now known as Eclair
[23:03:53] --> SB-X has joined #exult
[23:24:49] <-- SB-X has left IRC ("X-Chat")
[23:33:22] <-- servus has left IRC (Read error: 60 (Operation timed out))