From hook_l at pyrogon.com Sun Nov 2 12:06:19 2003 From: hook_l at pyrogon.com (Brian Hook) Date: Sun, 2 Nov 2003 12:06:19 -0500 Subject: Small update In-Reply-To: <2003810205210.634744@centrino> Message-ID: <200311212619.390090@centrino> After Nick guilted me into looking at the codebase again, I checked in some minor fixes for a few crash bugs. Adding a client game facility is going to be a pretty major architectural restructuring, which I don't want to take lightly. I really need to sit down and document the client flow. In Quake 2 there was basically a monolithic "client", which did both generic client stuff (interfacing to graphics, sound, network, etc.) and game specific stuff (client side prediction and effects). In Q3 this got split into two separate areas. I'd LIKE to split this up as well, since it makes mod-making even easier since you can add client side mod-specific effects. I've got that like 25% migrated, but it's not even in a separate DLL at this point and there's still a shit load of cross-contamination, but fixing it any further somewhat commits to some architectural decisions that I'm not quite comfortable making at this time. In the meantime, everything should mostly work. Brian From nick at rockstarvancouver.com Sun Nov 2 16:56:28 2003 From: nick at rockstarvancouver.com (Nick Trout) Date: Sun, 2 Nov 2003 13:56:28 -0800 Subject: [q2x] Small update Message-ID: <911F8C8EB7A8084AAEDD55CEDC54D8F851FB05@iggy.rockstarvancouver.com> > After Nick guilted me into looking at the codebase again, I checked in > some minor fixes for a few crash bugs. The old Vulcan mind-melt, with cheese... > Adding a client game facility is going to be a pretty major > architectural restructuring, which I don't want to take lightly. I > really need to sit down and document the client flow. Ooo docs, yes please. > In Quake 2 there was basically a monolithic "client", which did both > generic client stuff (interfacing to graphics, sound, network, etc.) > and game specific stuff (client side prediction and effects). In Q3 > this got split into two separate areas. Could we make the naming a little more intuitive? You have a qcommon and qshared, one is common game components and one is common code. The names seem interchangeable to me so it gets a little confusing. E.g. could be gamecommon and enginecommon? Also, client game is clgame, but server is just game. Shouldn't it be svgame? It may lead to people putting stuff in the wrong library in future. > I'd LIKE to split this up as well, since it makes mod-making even > easier since you can add client side mod-specific effects. > > I've got that like 25% migrated, but it's not even in a separate DLL > at this point and there's still a shit load of cross-contamination, > but fixing it any further somewhat commits to some architectural > decisions that I'm not quite comfortable making at this time. > > In the meantime, everything should mostly work. I've got latest CVS and I can't load anything! I'm using a Q2 demo for resources, and the exe for that runs fine on its own. I no longer get the wrong client/server version number errors, but I do get errors when the client requests a file but the server can't find it (I think this is what happens). Upgrading Physfs to v1.9 may help, otherwise has anyone else encountered this problem? Nick From hook_l at pyrogon.com Sun Nov 2 17:29:30 2003 From: hook_l at pyrogon.com (Brian Hook) Date: Sun, 2 Nov 2003 17:29:30 -0500 Subject: [q2x] Small update In-Reply-To: <911F8C8EB7A8084AAEDD55CEDC54D8F851FB05@iggy.rockstarvancouver.com> Message-ID: <2003112172930.468280@centrino> > Could we make the naming a little more intuitive? Yeah, I hear you, I'm just leery of changing too much away from the standard convention in place. And I still get confused as hell as well when looking at stuff! At the very least I think qcommon and qshared need to be split into gamecommon and enginecommon with appropriate GC_ and EC_ prefixes. I'll look into doing this "soon" =) > I've got latest CVS and I can't load anything! I'm using a Q2 demo > for resources, and the exe for that runs fine on its own. I don't think this works with Q2 demo resources, I believe you'll need the full game resources =/ I haven't encountered any other problems other than it reports it can't load some resources, but it still runs fine. Brian From nick at rockstarvancouver.com Sun Nov 2 17:44:40 2003 From: nick at rockstarvancouver.com (Nick Trout) Date: Sun, 2 Nov 2003 14:44:40 -0800 Subject: [q2x] Small update Message-ID: <911F8C8EB7A8084AAEDD55CEDC54D8F851FB09@iggy.rockstarvancouver.com> > From: Brian Hook [mailto:hook_l at pyrogon.com] > Sent: Sunday, November 02, 2003 2:30 PM > To: q2x at icculus.org > Subject: RE: [q2x] Small update > > > Could we make the naming a little more intuitive? > > Yeah, I hear you, I'm just leery of changing too much away from the > standard convention in place. And I still get confused as hell as > well when looking at stuff! > > At the very least I think qcommon and qshared need to be split into > gamecommon and enginecommon with appropriate GC_ and EC_ prefixes. > I'll look into doing this "soon" =) I'll have a think about this as well. > > I've got latest CVS and I can't load anything! I'm using a Q2 demo > > for resources, and the exe for that runs fine on its own. > > I don't think this works with Q2 demo resources, I believe you'll need > the full game resources =/ Ah, okay. I had a Q2 disc somewhere but I can't find it. I'll have to find a version in shop somewhere. > I haven't encountered any other problems other than it reports it > can't load some resources, but it still runs fine. Thanks for the quick response. It's beautiful day today so no more geeking for me until darkness. Nick From hook_l at pyrogon.com Wed Nov 5 15:24:38 2003 From: hook_l at pyrogon.com (Brian Hook) Date: Wed, 5 Nov 2003 15:24:38 -0500 Subject: Refactorization In-Reply-To: <2003810205210.634744@centrino> Message-ID: <2003115152438.534215@centrino> For my first pass of refactoring, I'm going to at least try to fix some of the naming nomenclature. I'm with Nick on this, it is pretty confusing. Unfortunately, the differences are still pretty subtle. QSHARED -> used by EVERYTHING, generic utility stuff QCOMMON -> shared by "native" components, like server/client, but not game DLLs QGAME -> shared between server-side game and server I can't think of really good names for the above that are clear and concise. The best I can think of: QSHARED -> QUTIL QCOMMON -> QCORE QGAME -> QGAME Prefixes would be adjusted, e.g. QU_*, QC_* and QG_* Brian From nick at rockstarvancouver.com Sat Nov 8 16:16:23 2003 From: nick at rockstarvancouver.com (Nick Trout) Date: Sat, 8 Nov 2003 13:16:23 -0800 Subject: [q2x] Refactorization Message-ID: <911F8C8EB7A8084AAEDD55CEDC54D8F851FB2A@iggy.rockstarvancouver.com> > -----Original Message----- > From: Brian Hook [mailto:hook_l at pyrogon.com] > Sent: Wednesday, November 05, 2003 12:25 PM > To: q2x at icculus.org > Subject: [q2x] Refactorization > > For my first pass of refactoring, I'm going to at least try to fix > some of the naming nomenclature. I'm with Nick on this, it is pretty > confusing. Unfortunately, the differences are still pretty subtle. > > QSHARED -> used by EVERYTHING, generic utility stuff > > QCOMMON -> shared by "native" components, like server/client, but not > game DLLs > > QGAME -> shared between server-side game and server > > I can't think of really good names for the above that are clear and > concise. The best I can think of: > > QSHARED -> QUTIL > > QCOMMON -> QCORE > > QGAME -> QGAME > > Prefixes would be adjusted, e.g. QU_*, QC_* and QG_* I'd suggest that the current naming convention, "Q_" is sufficient, and more intuitive than "QU_", i.e. everything in Quake uses "Q_" functions. Since the header is well grouped, and the "q_*.c" files well named, there is little confusion in finding the function implementation matching the declaration in qshared.h. If "common" is renamed then it makes "shared" less confusing, but since "shared" contains utility functions it makes sense to call it "qutil" (and it contains mostly project level reusable code). So, I think we just need to rename the library. Q2X contains all of the knarly startup code etc. The engine sitting on top of any common utility code is pretty Q2 oriented. There is a lot of hard-coded behaviour in there and it would be difficult abstract a very different game out this code. So, there seems little point trying to abstract generic client server architecture or other libraries. To that end I'd suggest the names: "QCORE", "QCLIENT" and "QSERVER" with QCORE containing as much common code as possible. In time most of the QSERVER code will migrate to Lua and the client and server libraries will become less dependent on Q2 nomenclature and objects; everything will be more data driven. Once all of the objects have been migrated it will be easier to abstract a cleaner client-server engine which could handle different types of game, however the technology of Quake is fairly directed at interior games and so there would seem little point. Since the code will be migrating to Lua this brings into play the Lua binding, where will this live? I think Brian mentioned that he didn't want Q2X to become dependent on Lua alone (from the depths of my scattered memory!), rather that it should be possible to embed other languages. If this were the case perhaps we need client and server binding libraries? My own opinion is that this would just confuse matters and you are better off putting the Lua binding in the client and server code. If we want to add another language at a later date the Lua binding could be refactored. From experience I don't know why you'd want to do this as Lua is incredibly flexible, efficient and more than adequate for the usage of this project. I'd also be interested in moving all of the Q2 config stuff over to Lua, e.g. cvars etc. Nick From nick at rockstarvancouver.com Sat Nov 8 16:27:12 2003 From: nick at rockstarvancouver.com (Nick Trout) Date: Sat, 8 Nov 2003 13:27:12 -0800 Subject: q2x Lua work Message-ID: <911F8C8EB7A8084AAEDD55CEDC54D8F851FB2B@iggy.rockstarvancouver.com> Dan Olson posted some Lua work a while back. It was a single Lua file demonstrating the work that had been done so far - a script, but no binding code. I can find "qlua_init()" but no other evidence of Lua work, will this be merged into q2x soon? Do we need to start afresh because of refactoring work? What is the status of this code? Nick From hook_l at pyrogon.com Sat Nov 8 19:15:47 2003 From: hook_l at pyrogon.com (Brian Hook) Date: Sat, 8 Nov 2003 19:15:47 -0500 Subject: [q2x] Refactorization In-Reply-To: <911F8C8EB7A8084AAEDD55CEDC54D8F851FB2A@iggy.rockstarvancouver.com> Message-ID: <2003118191547.454549@centrino> > I'd suggest that the current naming convention, "Q_" is sufficient, Ok. > So, there seems little point trying to abstract generic client > server architecture or other libraries. The abstraction isn't to make it more generic, it's actually just to enforce barriers between the subsystems to avoid unnecessary comingling and assumptions. > To that end I'd suggest the > names: "QCORE", "QCLIENT" and "QSERVER" with QCORE containing as > much common code as possible. The stuff shared between the client and server is really it's own thing because it's used by the built executable and not the DLLs. This is why there isn't a single monolithic lib that is shared + common. So we're still looking at four separate projects: QCLIENT, QSERVER, QCORE (everything) and QCOMMON (client and server)? > In time most of the QSERVER code will migrate to Lua and the client > and server libraries will become less dependent on Q2 nomenclature > and objects Actually, I think QSERVER will stay how it is, and most of the game/ code will end up becoming Lua. QSERVER is more engine-level server code (i.e. not game specific). > objects have been migrated it will be easier to abstract a cleaner > client-server engine which could handle different types of game, > however the technology of Quake is fairly directed at interior > games and so there would seem little point. The important thing is to handle different types of games within the genre. To make a really comprehensive mod requires hacking the client and server executables, not just the game DLLs. Q3 fixed this with QVM and I'd like to see Q2X eventually get to that point as well using Lua. > Since the code will be migrating to Lua this brings into play the > Lua binding, where will this live? I think Brian mentioned that he > didn't want Q2X to become dependent on Lua alone (from the depths > of my scattered memory!), rather that it should be possible to > embed other languages. If this were the case perhaps we need client > and server binding libraries? In a perfect world that's what i'd like to see, because there are other languages I could see being used as well such as Ruby and Python, but it's not a priority. The way I've envisioned it is that the server is game agnostic, it simply loads up the appropriate game DLL which can either be a directly executable DLL (as it is now) or it may just be a thunker, e.g. you'd make "gamelua.dll" and it would translate calls from the server to the Lua code. > could be refactored. From experience I don't know why you'd want to > do this as Lua is incredibly flexible, efficient and more than > adequate for the usage of this project. My biggest gripe, honestly, is that Lua doesn't have real-time GC and it's not typesafe. This can make larger scale projects a bit more tricky than I'd like. Brian From hook_l at pyrogon.com Sat Nov 8 19:16:11 2003 From: hook_l at pyrogon.com (Brian Hook) Date: Sat, 8 Nov 2003 19:16:11 -0500 Subject: [q2x] q2x Lua work In-Reply-To: <911F8C8EB7A8084AAEDD55CEDC54D8F851FB2B@iggy.rockstarvancouver.com> Message-ID: <2003118191611.243319@centrino> I don't think this was work was ever official, it was mostly Dan doing things speculatively to see what a first pass conversion might look like. On Sat, 8 Nov 2003 13:27:12 -0800, Nick Trout wrote: > > Dan Olson posted some Lua work a while back. It was a single Lua > file demonstrating the work that had been done so far - a script, > but no binding code. I can find "qlua_init()" but no other evidence > of Lua work, will this be merged into q2x soon? Do we need to start > afresh because of refactoring work? What is the status of this code? > > Nick From hook_l at pyrogon.com Sun Nov 9 00:02:10 2003 From: hook_l at pyrogon.com (Brian Hook) Date: Sun, 9 Nov 2003 00:02:10 -0500 Subject: [q2x] Refactorization In-Reply-To: <2003118191547.454549@centrino> Message-ID: <20031190210.563396@centrino> Baby steps. First pass is that I've renamed "qshared/" to "qutil/", adjusted DSP/DSW files to work (makefiles are not updated). Also renamed a couple other files. Otherwise should still work. So now we have: server/ client/ game/ qutil/ qcommon/ As our current major subsystems. I still really want to go through almost line by line and clean up huge scads of this shit before doing the extensions... Brian From nicktrout at shaw.ca Sun Nov 9 18:32:05 2003 From: nicktrout at shaw.ca (Nick Trout) Date: Sun, 09 Nov 2003 15:32:05 -0800 Subject: [q2x] Refactorization References: <2003118191547.454549@centrino> Message-ID: <003901c3a719$af816660$6400a8c0@quith1> >> could be refactored. From experience I don't know why you'd want to > do this as Lua is incredibly flexible, efficient and more than > adequate for the usage of this project. >My biggest gripe, honestly, is that Lua doesn't have real-time GC and it's not typesafe. This can make larger scale projects a bit more tricky than I'd like. Lua should have incremental GC early next year, and the language authors generally deliver good quality solutions. It's only a problem really if you are generating lots of objects which need to be collected. Code can be optimised to minimise this. I think Pythons GC is a hack and Python generates a lot more objects in use than Lua. Although I love Python I don't think its a realtime/game language. I can't find any reference to Ruby having incremental GC, it has a mark and sweep GC, like Lua, so you'd have all the same problems. Python is dynamically typed as well as Lua, but I think Ruby is statically typed. I've programmed a lot more Python than Lua and I've never missed static typing. It doesn't affect scalability and its a less hassle. The only time you really need typing is when you're dealing with binary formatting and Python has libraries for that (e.g. struct and array). Nick From hook_l at pyrogon.com Sun Nov 9 19:28:55 2003 From: hook_l at pyrogon.com (Brian Hook) Date: Sun, 9 Nov 2003 19:28:55 -0500 Subject: [q2x] Refactorization In-Reply-To: <003901c3a719$af816660$6400a8c0@quith1> Message-ID: <2003119192855.010864@centrino> > Python is dynamically typed as well as Lua, but I think Ruby is > statically typed. I've programmed a lot more Python than Lua and > I've never missed static typing. It doesn't affect scalability and > its a less hassle. The problem is that you can't make a method that takes "two objects of type X" and have the compiler catch this (at least, I believe you can't do this in Lua). Without this feature, it's entirely too easy to accidentally pass parameters of the wrong type to a function. Where this becomes a problem is when you have projects with lots of programmers and someone forgets/doesn't realize that you need to use certain types in a particular method. Don't get me wrong, I'm not a fan of hardcore static type checking, but it is useful in some areas. My preference is something like Obj-C, which has both. Brian From jaq at spacepants.org Mon Nov 10 01:24:12 2003 From: jaq at spacepants.org (Jamie Wilkinson) Date: Mon, 10 Nov 2003 17:24:12 +1100 Subject: [q2x] Refactorization In-Reply-To: <003901c3a719$af816660$6400a8c0@quith1> References: <2003118191547.454549@centrino> <003901c3a719$af816660$6400a8c0@quith1> Message-ID: <20031110062411.GC21110@spacepants.org> This one time, at band camp, Nick Trout wrote: >optimised to minimise this. I think Pythons GC is a hack and Python >generates a lot more objects in use than Lua. Although I love Python I don't >think its a realtime/game language. Microforte (Melbourne, Australia) are building a game called Citizen Zero around their BigWorld engine, a massively multiplayer RPG. They're using Python as the scripting language, it was quite impressive when I saw it run. Of course, they didn't go into details about the performance issues of the interpreter, and I'm sure the fact that it still isn't released after 3 or so years of development has anything to do with Python's GC :-) -- jaq at spacepants.org http://spacepants.org/jaq.gpg From nicktrout at shaw.ca Mon Nov 10 12:25:38 2003 From: nicktrout at shaw.ca (Nick Trout) Date: Mon, 10 Nov 2003 09:25:38 -0800 Subject: [q2x] Refactorization References: <2003118191547.454549@centrino> <003901c3a719$af816660$6400a8c0@quith1> <20031110062411.GC21110@spacepants.org> Message-ID: <001501c3a7af$a8ac37c0$6400a8c0@quith1> From: "Jamie Wilkinson" > This one time, at band camp, Nick Trout wrote: > >optimised to minimise this. I think Pythons GC is a hack and Python > >generates a lot more objects in use than Lua. Although I love Python I don't > >think its a realtime/game language. > > Microforte (Melbourne, Australia) are building a game called Citizen Zero > around their BigWorld engine, a massively multiplayer RPG. They're using > Python as the scripting language, it was quite impressive when I saw it run. > Of course, they didn't go into details about the performance issues of the > interpreter, and I'm sure the fact that it still isn't released after 3 or > so years of development has anything to do with Python's GC :-) The other issue with Python is the core is not reentrant, so you have mutexs everywhere and big inefficiency when multithreading. Let me reiterate, I really like Python, but the way it has been written is "let's get the syntax correct and then sort out the implementation". Python 3 (from what I remember) is where I think they're planning to do this. In a way the first 2 versions are prototypes (plan for a prototype as you'll end up throwing one version away anyway...), as the language evolves, for which v3 will be a complete reimplementation. Its quite sensible to do it this way really (premature optimisation and all that). In Lua, the implementation and syntax have always had equal importance. Lua also has a much smaller implementation and is lean on features so this is not such a monolithic task. Any comments about the delay of this game would be pure speculation. It's easy to underestimate the amount of time and resources necessary to get a game like this off the ground. There are a lot of problems you have to deal with when you scale a game world up. Nick From nicktrout at shaw.ca Mon Nov 10 12:38:25 2003 From: nicktrout at shaw.ca (Nick Trout) Date: Mon, 10 Nov 2003 09:38:25 -0800 Subject: [q2x] Refactorization References: <2003119192855.010864@centrino> Message-ID: <002101c3a7b1$71944be0$6400a8c0@quith1> >From: "Brian Hook" > Python is dynamically typed as well as Lua, but I think Ruby is > statically typed. I've programmed a lot more Python than Lua and > I've never missed static typing. It doesn't affect scalability and > its a less hassle. > The problem is that you can't make a method that takes "two objects of type X" and have the compiler catch this (at least, I believe you can't do this in Lua). Without this feature, it's entirely too easy to accidentally pass parameters of the wrong type to a function. You're right, but no dynamically typed language can as you obviously don't know the type until runtime. You can of course check the type at runtime, but I think problems like this are rare and can be fixed with documentation. If we did want to do something like this you could wrap each function you wanted to check, e.g. function foo(a,b) -- 2 numbers return a*b end check_params('foo', 'number', 'number') -- for debug You don't really want to be doing type checking (efficiency issue), and doing it this way you could just turn the functionality on for the debug version. You might even generate this type wrappers automatically from the docs. >Where this becomes a problem is when you have projects with lots of programmers and someone forgets/doesn't realize that you need to use certain types in a particular method. Docs! A simple comment with each function will fix this. I added a document generator (selfdoc) to my GL project http://doris.sf.net/ > Don't get me wrong, I'm not a fan of hardcore static type checking, but it is useful in some areas. My preference is something like Obj-C, which has both. Haven't used Obj-C, I should look it up some time. Nick From hook_l at pyrogon.com Mon Nov 10 13:35:41 2003 From: hook_l at pyrogon.com (Brian Hook) Date: Mon, 10 Nov 2003 13:35:41 -0500 Subject: [q2x] Refactorization In-Reply-To: <002101c3a7b1$71944be0$6400a8c0@quith1> Message-ID: <20031110133541.394546@centrino> > You're right, but no dynamically typed language can as you No PURELY dynamically typed language can do this =) > Docs! A simple comment with each function will fix this. I added a > document generator (selfdoc) to my GL project http://doris.sf.net/ Sure, "docs and unit testing" ensure this, but having it caught at compile time when something slips under the radar can save a huge amount of headache later. > Haven't used Obj-C, I should look it up some time. The documentation is free at developer.apple.com. It's the most brilliantly executed OOP language ever, period. Brian From hook_l at pyrogon.com Wed Nov 12 01:02:35 2003 From: hook_l at pyrogon.com (Brian Hook) Date: Wed, 12 Nov 2003 01:02:35 -0500 Subject: [q2x] Refactorization In-Reply-To: <20031110133541.394546@centrino> Message-ID: <200311121235.073531@centrino> I'm in the midst of a gnarly global update (s/byte/qbyte). Bleh. Anyway, opinions on whether to keep the software renderer or not? I'm pretty torn about this. On the one hand, running on low-end systems reliably would be kind of nice for any project. On the other hand, being able to rip out all semblance of paletted support would be nice (unfortunately, PCX support would still have to remain because a lot of stock assets are still in PCX form). The engineer in me really likes deleting code and minimizing maintenance. The pragmatist in me, however, would really like to keep the ability to run on shitty machines. I'm leaning towards ripping it out, because it should be easy enough to run reliably on even basic 3D acceleration from 1998. BTW, the missing asset error messages were the result of a bug in physics fs which has been fixed. Brian From nicktrout at shaw.ca Wed Nov 12 13:10:14 2003 From: nicktrout at shaw.ca (Nick Trout) Date: Wed, 12 Nov 2003 10:10:14 -0800 Subject: [q2x] Refactorization References: <200311121235.073531@centrino> Message-ID: <003701c3a948$38618340$6400a8c0@quith1> > I'm in the midst of a gnarly global update (s/byte/qbyte). Bleh. You'd think we'd have better tools for this these days wouldn't you?! Global renaming and context aware renaming etc. What are you using? > Anyway, opinions on whether to keep the software renderer or not? I'm pretty torn about this. I suppose the Quake s/w renderer is kind of nostalgic because it was the first game to have such advanced 3d features. But, you're right, even the most basic 3d cards these days ($40!) can render Q2 no problem, so I'd have to say cut it. I'm quite happy to leave the call entirely up to you though. I'm not a PC assembler guru so I couldn't add features or maintain it. If we went with the GL one (which lets face it GL is the new gfx baseline) we could add new features. I know isnt a goal of this project, but it would be nice to have the option. > (unfortunately, PCX support would still have to remain because a lot of stock assets are still in PCX form). Eventually, perhaps we could supply a whole new pack file with different assets to avoid licensing problems. We could ask some artists to get involved? > BTW, the missing asset error messages were the result of a bug in physics fs which has been fixed. Great. I'll try and build that sometime soon. Nick From laurent.desnogues at wanadoo.fr Wed Nov 12 17:35:45 2003 From: laurent.desnogues at wanadoo.fr (Laurent Desnogues) Date: Wed, 12 Nov 2003 23:35:45 +0100 Subject: [q2x] Refactorization References: <200311121235.073531@centrino> Message-ID: <007001c3a96d$5073c680$450000c0@4st060j> Brian wrote: > > Anyway, opinions on whether to keep the software renderer or not? I have one argument to keep the SW renderer: it's the only way I can compile it on my PS2 which does not have an OpenGL library. I guess this may be representative of most "embedded" target such as PocketPC... Anyway I think getting rid of it may be more profitable on all systems in the middle-term. Laurent From hook_l at pyrogon.com Wed Nov 12 17:48:09 2003 From: hook_l at pyrogon.com (Brian Hook) Date: Wed, 12 Nov 2003 17:48:09 -0500 Subject: [q2x] Refactorization In-Reply-To: <007001c3a96d$5073c680$450000c0@4st060j> Message-ID: <2003111217489.590500@centrino> > I have one argument to keep the SW renderer: it's the only way I > can compile it on my PS2 which does not have an OpenGL library. Heh...well, I doubt the Q2X source base will be PS2 (or PPC) compatible anyways. If anything, if someone were to support the PS2, I'd encourage them to write a ref_ps2 and get hardware acceleration that way. Software rendering on a PS2 seems so...wrong. Brian From hook_l at pyrogon.com Wed Nov 12 17:50:14 2003 From: hook_l at pyrogon.com (Brian Hook) Date: Wed, 12 Nov 2003 17:50:14 -0500 Subject: [q2x] Refactorization In-Reply-To: <003701c3a948$38618340$6400a8c0@quith1> Message-ID: <20031112175014.172663@centrino> > You'd think we'd have better tools for this these days wouldn't > you?! Global renaming and context aware renaming etc. What are you > using? Find in Files in VC++ =/ I don't like using perl or sed for this because if you screw up the regex you may have just trashed your entire local file repository. > couldn't add features or maintain it. If we went with the GL one > (which lets face it GL is the new gfx baseline) we could add new > features. I know isnt a goal of this project, but it would be nice > to have the option. Yeah, I'm leaning towards that direction. > Eventually, perhaps we could supply a whole new pack file with > different assets to avoid licensing problems. We could ask some > artists to get involved? In fact, I believe someone is already doing this, a GPL texture pack for Q2. I think it's called the "Q2 retexturing project" or something like that. > Great. I'll try and build that sometime soon. Cool, let me know how it goes. Hmmm, you know what? Screw it, I'm going to toast the software renderer. Less crap to maintain is a Good Thing. =) Brian From nicktrout at shaw.ca Wed Nov 12 18:15:07 2003 From: nicktrout at shaw.ca (Nick Trout) Date: Wed, 12 Nov 2003 15:15:07 -0800 Subject: [q2x] Refactorization References: <2003111217489.590500@centrino> Message-ID: <007a01c3a972$d0350f50$6400a8c0@quith1> ----- Original Message ----- From: "Brian Hook" To: Sent: Wednesday, November 12, 2003 2:48 PM Subject: Re: [q2x] Refactorization > I have one argument to keep the SW renderer: it's the only way I > can compile it on my PS2 which does not have an OpenGL library. > Heh...well, I doubt the Q2X source base will be PS2 (or PPC) compatible anyways. If anything, if someone were to support the PS2, I'd encourage them to write a ref_ps2 and get hardware acceleration that way. There is ps2gl. It's a project on the ps2 support site. I haven't used it but I think a fair amount of effort went into it. > Software rendering on a PS2 seems so...wrong. I suppose its one extreme or the other on that machine. Render to texture and blit, or DMA/hardware hell! Nick From hook_l at pyrogon.com Wed Nov 12 18:48:08 2003 From: hook_l at pyrogon.com (Brian Hook) Date: Wed, 12 Nov 2003 18:48:08 -0500 Subject: Cinematics In-Reply-To: <007a01c3a972$d0350f50$6400a8c0@quith1> Message-ID: <2003111218488.150051@centrino> Q2 has its own antiquated cinematics engine. I don't anticipate using the existing cinematics for much longer, and for modern cinematics I'm assuming that there is some open source motion compression solution available? If there is, which one would we use? I'd like to ditch the existing stuff right now, if possible, and then bolt on new cinematics if there is even demand for it. Brian From jaq at spacepants.org Thu Nov 13 08:00:29 2003 From: jaq at spacepants.org (Jamie Wilkinson) Date: Fri, 14 Nov 2003 00:00:29 +1100 Subject: [q2x] Cinematics In-Reply-To: <2003111218488.150051@centrino> References: <007a01c3a972$d0350f50$6400a8c0@quith1> <2003111218488.150051@centrino> Message-ID: <20031113130029.GC9697@spacepants.org> This one time, at band camp, Brian Hook wrote: >If there is, which one would we use? I'd like to ditch the existing >stuff right now, if possible, and then bolt on new cinematics if there >is even demand for it. Ogg Theora is still in alpha at the moment, but it's looking promising. Unfortunately there are no stable released versions available to do development against (that I know of). -- jaq at spacepants.org http://spacepants.org/jaq.gpg From hook_l at pyrogon.com Wed Nov 19 15:56:21 2003 From: hook_l at pyrogon.com (Brian Hook) Date: Wed, 19 Nov 2003 15:56:21 -0500 Subject: [q2x] Cinematics In-Reply-To: <20031113130029.GC9697@spacepants.org> Message-ID: <20031119155621.669664@centrino> I've decided to remove the .CIN file support for now, but I'm keeping in the stubs for general cinematic support. Also, here's a link to the Q2 retexturing project: http://texture.dragonwerks.ca/ I'm currently doing a global s/true/qtrue and s/false/qfalse...bleh. Brian From hook_l at pyrogon.com Wed Nov 19 21:50:51 2003 From: hook_l at pyrogon.com (Brian Hook) Date: Wed, 19 Nov 2003 21:50:51 -0500 Subject: CD Audio In-Reply-To: <20031119155621.669664@centrino> Message-ID: <20031119215051.806661@centrino> Anyone opposed to me trashing CD audio support? -Hook, "addition through subtraction" From nick at rockstarvancouver.com Wed Nov 19 21:56:05 2003 From: nick at rockstarvancouver.com (Nick Trout) Date: Wed, 19 Nov 2003 18:56:05 -0800 Subject: [q2x] CD Audio Message-ID: <911F8C8EB7A8084AAEDD55CEDC54D8F851FB6F@iggy.rockstarvancouver.com> Nah. I can't imagine anyone is going to be distributing CDs of work done with Q2X? We should be using MP3 or OGG for any background audio which makes it easier to distribute web wise (or on smaller CD distributions). Nick > -----Original Message----- > From: Brian Hook [mailto:hook_l at pyrogon.com] > Sent: Wednesday, November 19, 2003 6:51 PM > To: q2x at icculus.org > Subject: [q2x] CD Audio > > Anyone opposed to me trashing CD audio support? > > -Hook, "addition through subtraction" > From hook_l at pyrogon.com Wed Nov 19 22:03:52 2003 From: hook_l at pyrogon.com (Brian Hook) Date: Wed, 19 Nov 2003 22:03:52 -0500 Subject: [q2x] CD Audio In-Reply-To: <911F8C8EB7A8084AAEDD55CEDC54D8F851FB6F@iggy.rockstarvancouver.com> Message-ID: <2003111922352.938887@centrino> That's what I assume as well. Okay, it's gone. I've commented out the cinematics stuff as well, and I'm ready to commit 100% to using the Physics_FS stuff (it's used right now, but can be replaced with stdio with a simple #define change). Brian On Wed, 19 Nov 2003 18:56:05 -0800, Nick Trout wrote: > > > Nah. I can't imagine anyone is going to be distributing CDs of work > done with Q2X? We should be using MP3 or OGG for any background > audio which makes it easier to distribute web wise (or on smaller > CD distributions). > > Nick > > >> -----Original Message----- >> From: Brian Hook [mailto:hook_l at pyrogon.com] >> Sent: Wednesday, November 19, 2003 6:51 PM >> To: q2x at icculus.org >> Subject: [q2x] CD Audio >> >> >> Anyone opposed to me trashing CD audio support? >> >> >> -Hook, "addition through subtraction"