[10:44pm] Lilman424 sets mode: +m

[10:44pm] <ken52787[GA]> anyone care to start?

[10:44pm] <Hellfire[OC]> Ok. So who has anything to add?

[10:46pm] <ken52787[GA]> nice ice breaker

[10:46pm] <Rein[GP]> ok, so, what’s the meeting main topic?

[10:47pm] <Lilman424> Um...The engine?

[10:48pm] <Lilman424> and.....about releasing the source code and such

[10:48pm] <Rein[GP]> Generally: I’ve just finished object managing (low level) stuff

[10:48pm] <Lilman424> HEX wants to know: 

[10:48pm] <Lilman424> [03:47:49] <HEXerium> Question this: How much objects can the engine handle?

[10:49pm] <Hellfire[OC]> That will depend:

[10:49pm] <Rein[GP]> enhanced existing classes and merged them into dynamic pools instead of those stupid arrays

[10:49pm] <Rein[GP]> there won't be a hard limit of objects

[10:49pm] <Hellfire[OC]> but there will be on how fast those can all be rendered.

[10:49pm] <Rein[GP]> they're allocated dynamically

[10:49pm] <Rein[GP]> yes...

[10:49pm] <ken52787[GA]> So basically, it’s however much any given PC can handle before crashing?

[10:50pm] <Rein[GP]> that’s right

[10:50pm] <Rein[GP]> but in order to prevent crashing there'll probably a 'soft limit'

[10:50pm] <Hellfire[OC]> crashing? We're writing quality software here. It won't crash given any load (at least, if there's 
going to be a Linux port, it will)

[10:50pm] <Rein[GP]> (* declared in .ini file due to RAM capacity)

[10:51pm] <Rein[GP]> hehe

[10:51pm] <ken52787[GA]> that sounds good

[10:51pm] <Hellfire[OC]> But in order to keep some form of performance, the game shouldn't use more memory than the machine has.

[10:51pm] <Hellfire[OC]> swap = evil

[10:51pm] <ken52787[GA]> yes, swap files are slow

[10:51pm] <Rein[GP]> yea Hellfire, just wait for 128 companies, with 256 players in each where each controls 65535 objects :D

[10:52pm] <Lilman424>  <HEXerium> Q: In witch is the engine extendable. I mean; is it easy to add new pieces to the code. Like if I want to add something. Should I know the entire source or can the "new" code easily be included?

[10:52pm] <Hellfire[OC]> Rein: Can you find a sponsor for a server that can handle that much load?

[10:52pm] <Rein[GP]> it hardly depends on what kind of addition you're about to make

[10:52pm] <ken52787[GA]> I'm sure as we progress, and if everything goes as planned, we can leech that 1gbit server :-)

[10:52pm] <Rein[GP]> Hellfire: no

[10:53pm] <Rein[GP]> I don’t take care of net stuff, even server-client architecture will be hardly consulted with other coders

[10:53pm] <Rein[GP]> I'd propose rather a multi-server system

[10:53pm] <Hellfire[OC]> That will be necessary, yes.

[10:54pm] <Rein[GP]> ow, Hellfire, I'd love to ask you to fill up the MESHes code (loading/rendering/handling 3d data and so)

[10:54pm] <Hellfire[OC]> ok. 

[10:54pm] <Rein[GP]> as soon as the source is given to you

[10:54pm] <Hellfire[OC]> :) I was just going to ask

[10:55pm] <Rein[GP]> some docs are necessary

[10:55pm] <Rein[GP]> general engine's structure has changed a lot since that old good src0004 version ;)

[10:55pm] <Hellfire[OC]> probably, yes. And maybe an optimized custom mesh file format. But I'll look into that when I'm coding.

[10:56pm] <Hellfire[OC]> You gave me the src0005 version as well.

[10:56pm] <Rein[GP]> yea, there are just null structures and functions waiting to filling

[10:56pm] <Rein[GP]> 0005? ow, that was a first step in a way of improving the struct

[10:57pm] <Hellfire[OC]> Great! Can't wait to start coding! ooh. wait.. design and specs come first :(

[10:57pm] <ken52787[GA]> I know some C++ and can probably help with simpler tasks if you need it

[10:57pm] <Rein[GP]> bug-tracking ;D

[10:57pm] <ken52787[GA]> ::bows head:: damn :-)

[10:57pm] <Rein[GP]> just kidding ;)

[10:58pm] <Hellfire[OC]> I wonder whether we could give Ken or Evan an algorithm design.. And let them implement it...

[10:58pm] <Lilman424> What's the situation with the Design Docs?

[10:58pm] <Lilman424> algorithm design?

[10:58pm] <Rein[GP]> STATUS: there aren't any apart from engine's classes’ docs

[10:59pm] <Rein[GP]> general architecture needs to be enclosed in a graph

[10:59pm] <Hellfire[OC]> Rein: have you looked into pathfinding and/or (rail)road data representation?

[11:00pm] <Rein[GP]> yes, but not in order to implement it yet

[11:00pm] <Rein[GP]> modified A* is a solution

[11:00pm] <Rein[GP]> which doesn't take whole map into account but only road/rail connection

[11:01pm] <Rein[GP]> I was puzzling on rail signs blocks...and handling them


[11:01pm] <Hellfire[OC]> Yes, that can be a real hard one.

[11:02pm] <Rein[GP]> and what I made up is a system of dynamic std::vectors which keep single tracks between signs

[11:02pm] <Hellfire[OC]> I was thinking that each block should have a list of entries and a list of exist (which can overlap), and for each entry, one train could be waiting.

[11:03pm] <Rein[GP]> something like this

[11:03pm] <Rein[GP]> only handling them in memory may be bloody for memory

[11:04pm] <Hellfire[OC]> Do they take so much memory?

[11:04pm] <Rein[GP]> Hellfire: texture handling, instead of using one general texture pool I decided to make textures lists in every class where it's necessary

[11:05pm] <Hellfire[OC]> Any reason? Or is the latter faster?

[11:05pm] <Rein[GP]> every block has to keep pointers to all the other blocks placed directly

[11:05pm] <Rein[GP]> TEX: we don't have to use pointers to every texture (from GUI, TERRAIN RENDERER, OBJECT RENERER etc.)

[11:06pm] <Rein[GP]> every class will has its own unique textures

[11:08pm] <Lilman424> [04:07:56] <HEXerium> Q: Do you already have an idea on which systems it's gonna work? Like what are the min. system specs you need?

[11:08pm] <Lilman424> [04:08:03] <HEXerium>Q: Which compilers are Rein and Hellfire using?

[11:08pm] <Hellfire[OC]> Visual C++ 

[11:09pm] <ken52787[GA]> ooh, that’s what I use

[11:09pm] <Lilman424> [04:08:03] <HEXerium> Q: The zoom levels, how much do they FPS do they eat? I know this was on the forums before, but I want to know if you already improved this somehow. It wouldn't work nice if you lose too much FPS when zooming in.

[11:09pm] <Rein[GP]> (Q1): no idea, I’m sure it won’t run well on my pIII666 ;)

[11:09pm] <Lilman424> that's what I use too, but it won't work. :(

[11:09pm] <Rein[GP]> (Q2) MSVC++6.0 (me)

[11:09pm] <ken52787[GA]> I have 6.0, got it for like $35

[11:09pm] <Lilman424> so we all use MSVC++

[11:10pm] <Hellfire[OC]> (Q1): I think that it will run on today's new budget hardware (which will be mainstream by the time the game comes available)

[11:10pm] <Rein[GP]> (Q3) at normal zoom I reach 30 fps but when zooming out it drops down below 1.0 :/

[11:10pm] <Lilman424> I got it in a learning book; SAMS teach yourself C in 21 days

[11:10pm] <Rein[GP]> we have to implement good LOD algorithms both for objects and terrain to keep fps at reasonable stage

[11:10pm] <Hellfire[OC]> (Q3) at normal zoom, I reach over 400 fps. But when zooming out it drops down to 5.0 (unoptimized code)

[11:11pm] <Hellfire[OC]> forgot to mention: I have a way too heavy gaming rig. :)

[11:11pm] <Lilman424> but, remember, there's no objects yet

[11:11pm] <Hellfire[OC]> That's true. Ideally, objects will have some form of LOD too.

[11:12pm] <Rein[GP]> uh, have you noticed Hellfire that the framing of the drawn tiles is hardcoded and unjustifiable (ab. 40 tiles in a row and col ;)

[11:12pm] <Hellfire[OC]> yes, I have noticed that it's hardcoded. (it isn't present in src0005)

[11:13pm] <Hellfire[OC]> or am I off your point here?

[11:13pm] <Rein[GP]> I cant recall it now

[11:14pm] <Rein[GP]> there are variables iTilesOnScreenX and Y (or sth like that) which ought to be dynamically updated while zooming)

[11:15pm] <Hellfire[OC]> but they already are :S

[11:15pm] <Hellfire[OC]> the values are a bit off, but they are dynamic.

End of On-topic discussion