You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(4) |
Oct
(27) |
Nov
(3) |
Dec
(5) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(71) |
Feb
(27) |
Mar
(17) |
Apr
(18) |
May
(2) |
Jun
(11) |
Jul
(2) |
Aug
|
Sep
|
Oct
(11) |
Nov
(12) |
Dec
|
2003 |
Jan
|
Feb
(5) |
Mar
(5) |
Apr
(2) |
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(8) |
Dec
|
2004 |
Jan
(2) |
Feb
(1) |
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
From: Andres R. <and...@ho...> - 2002-01-25 04:02:00
|
Now that I've done it as a console app, it compiles, but doesn't do = anything but create the default console window with the "press any key" = message, and that's it... int main(int argc, char** argv) { // GLUT Window Initialization: glutInit (&argc, argv); glutInitWindowSize (800,600); glutInitDisplayMode ( GLUT_RGB | GLUT_DOUBLE | GLUT_DEPTH); glutCreateWindow ("Andres G L U T"); InitGraphics(); glutDisplayFunc (display); ... |
From: Ben S. <bs...@vr...> - 2002-01-25 03:40:03
|
on the other hand, you could just add this code to your current project: #ifdef _WIN32 #ifndef _CONSOLE int WINAPI WinMain( HINSTANCE instance, HINSTANCE prevInstance, LPSTR commandLine int showCommand ) { return main( __argc, __argv ); } ----- Ben Scott President ISU Game Developers Club Treasurer ISU Ballroom Dance Company bs...@ia... On Thu, 24 Jan 2002, Ben Scott wrote: > ahh, you probably created a new win32 project in VC++. Projects created in > that manner actually start in the function WinMain( ... ) instead of > main( ... ). > > the easiest way to fix this is to create a new "win32 console" project > that will use main( ... ). > > cheers, > ----- > Ben Scott > President ISU Game Developers Club > Treasurer ISU Ballroom Dance Company > bs...@ia... > > On Thu, 24 Jan 2002, Andres Reinot wrote: > > > alright, I'm now getting this error: > > > > LIBC.lib(wincrt0.obj) : error LNK2001: unresolved external symbol > > _WinMain@16 > > does this have anything to do with the GLUT libraries? > > > > And where's the source for the square example we did today? > > > > > > > > _______________________________________________ > > ISUGameDev-devel mailing list > > ISU...@li... > > https://lists.sourceforge.net/lists/listinfo/isugamedev-devel > > > > > _______________________________________________ > ISUGameDev-devel mailing list > ISU...@li... > https://lists.sourceforge.net/lists/listinfo/isugamedev-devel > |
From: Kevin M. <ke...@vr...> - 2002-01-25 03:38:55
|
I generally make a "new console project" from the new menu. then simply add glut.lib OpenGL32.lib glu32.lib to the libs tab of the project/settings menu... I've not seen the error you're getting... Maybe you are compiling a 16 bit windows application? It is expecting WinMain, which you don't need in a console app, but you do need in a Win32 app... but winmain16 seems funny, like you made a 16 bit project or something... Try recreating your project and see if that works... @--@---@---@----@-----@------@------@-----@----@---@---@--@ Kevin Meinert __ _ __ http://www.vrac.iastate.edu/~kevn \ || \| \ / ` Virtual Reality Applications Center \ ||.-'|--\ Howe Hall, Iowa State University, Ames Iowa \|| \| \`__, ----------------------------------------------------------- On Thu, 24 Jan 2002, Andres Reinot wrote: > alright, I'm now getting this error: > > LIBC.lib(wincrt0.obj) : error LNK2001: unresolved external symbol > _WinMain@16 > does this have anything to do with the GLUT libraries? > > And where's the source for the square example we did today? > > > > _______________________________________________ > ISUGameDev-devel mailing list > ISU...@li... > https://lists.sourceforge.net/lists/listinfo/isugamedev-devel > |
From: Ben S. <bs...@vr...> - 2002-01-25 03:37:33
|
ahh, you probably created a new win32 project in VC++. Projects created in that manner actually start in the function WinMain( ... ) instead of main( ... ). the easiest way to fix this is to create a new "win32 console" project that will use main( ... ). cheers, ----- Ben Scott President ISU Game Developers Club Treasurer ISU Ballroom Dance Company bs...@ia... On Thu, 24 Jan 2002, Andres Reinot wrote: > alright, I'm now getting this error: > > LIBC.lib(wincrt0.obj) : error LNK2001: unresolved external symbol > _WinMain@16 > does this have anything to do with the GLUT libraries? > > And where's the source for the square example we did today? > > > > _______________________________________________ > ISUGameDev-devel mailing list > ISU...@li... > https://lists.sourceforge.net/lists/listinfo/isugamedev-devel > |
From: Kevin M. <ke...@vr...> - 2002-01-25 03:35:07
|
In addition, you'll need to add glut.lib OpenGL32.lib Glu32.lib to your libs in the VC++ project settings... @--@---@---@----@-----@------@------@-----@----@---@---@--@ Kevin Meinert __ _ __ http://www.vrac.iastate.edu/~kevn \ || \| \ / ` Virtual Reality Applications Center \ ||.-'|--\ Howe Hall, Iowa State University, Ames Iowa \|| \| \`__, ----------------------------------------------------------- On Thu, 24 Jan 2002, Kevin Meinert wrote: > > I typically do this: > > put the glut.h into your msvc++ include\GL\ directory > put the glut.lib into your msvc++ lib\ directory > put the glut.dll into your c:\windows\system directory > > This effectively installs glut for use by visual studio. > > > you'll probably see that your other opengl stuff (that comes with VC++) is > in similar places: > > include\GL\gl.h > include\GL\glu.h > lib\glu32.lib > lib\OpenGL32.lib > > > Where the root dir is on your system depends on where you installed msvc++ > to... if all else fails, just do a file search for glu.h and you'll find > where to put your headers. > > @--@---@---@----@-----@------@------@-----@----@---@---@--@ > Kevin Meinert __ _ __ > http://www.vrac.iastate.edu/~kevn \ || \| \ / ` > Virtual Reality Applications Center \ ||.-'|--\ > Howe Hall, Iowa State University, Ames Iowa \|| \| \`__, > ----------------------------------------------------------- > > On Thu, 24 Jan 2002, Andres Reinot wrote: > > > Ok, in MSVC 6, how do I set up GLUT so that it WORKS? > > which folders to the headers, dll's and libs go to, and do I need to do something inside MSVC? like mess with parsing or something? > > > > > _______________________________________________ > ISUGameDev-devel mailing list > ISU...@li... > https://lists.sourceforge.net/lists/listinfo/isugamedev-devel > |
From: Andres R. <and...@ho...> - 2002-01-25 03:34:46
|
alright, I'm now getting this error: LIBC.lib(wincrt0.obj) : error LNK2001: unresolved external symbol _WinMain@16 does this have anything to do with the GLUT libraries? And where's the source for the square example we did today? |
From: Kevin M. <ke...@vr...> - 2002-01-25 03:25:12
|
I typically do this: put the glut.h into your msvc++ include\GL\ directory put the glut.lib into your msvc++ lib\ directory put the glut.dll into your c:\windows\system directory This effectively installs glut for use by visual studio. you'll probably see that your other opengl stuff (that comes with VC++) is in similar places: include\GL\gl.h include\GL\glu.h lib\glu32.lib lib\OpenGL32.lib Where the root dir is on your system depends on where you installed msvc++ to... if all else fails, just do a file search for glu.h and you'll find where to put your headers. @--@---@---@----@-----@------@------@-----@----@---@---@--@ Kevin Meinert __ _ __ http://www.vrac.iastate.edu/~kevn \ || \| \ / ` Virtual Reality Applications Center \ ||.-'|--\ Howe Hall, Iowa State University, Ames Iowa \|| \| \`__, ----------------------------------------------------------- On Thu, 24 Jan 2002, Andres Reinot wrote: > Ok, in MSVC 6, how do I set up GLUT so that it WORKS? > which folders to the headers, dll's and libs go to, and do I need to do something inside MSVC? like mess with parsing or something? > |
From: Andres R. <and...@ho...> - 2002-01-25 03:20:45
|
Ok, in MSVC 6, how do I set up GLUT so that it WORKS? which folders to the headers, dll's and libs go to, and do I need to do = something inside MSVC? like mess with parsing or something? |
From: Kevin M. <ke...@vr...> - 2002-01-22 22:39:18
|
On Tue, 22 Jan 2002, Chad Austin wrote: > Okay, I guess the question now is... where should the CVS organization doc go? > :) in the FAQ on the web site? I think all the docs should go there... the only bad thing is we don't get revision control on it, but it is a nicely managed FAQ area... > > And instead of |cvs co projects|, people could always do |cvs co > projects/myproject| > this is true... basically it was to make it easier to get a project (not as much typing). also having an aki module makes more sense than having a project module that aki is within - sinse aki is standalone. The lib module is different, since each project would depend on it, it would be easiest to put all common code there. I think organizing the repos for aesthetics might not be right, it isn't a directory structure, it is a collection of modules. (this isn't really a strong argument though..) The only hangup I have is that viewing the cvs source might become harder - but is this a good reason to have one module with all projects a part of it? kevin > > I think the current state is that the stuff in projects is getting moved > > to root, and the xdl dir is getting removed (because it is in the lib > > dir). > > > > ben and i were discussing this, and decided it would be annoying to check > > out the projects module and get everyone's project at once... > > > > > We need a document that describes where things go in CVS. I'm very much > > > confused. And as we all know, confusion means something should be written > > > down. :) > -- @--@---@---@----@-----@------@------@-----@----@---@---@--@ Kevin Meinert __ _ __ http://www.vrac.iastate.edu/~kevn \ || \| \ / ` Virtual Reality Applications Center \ ||.-'|--\\ Howe Hall, Iowa State University, Ames Iowa \|| \| \`__, ----------------------------------------------------------- |
From: Chad A. <ae...@ae...> - 2002-01-22 22:32:19
|
Okay, I guess the question now is... where should the CVS organization doc go? :) And instead of |cvs co projects|, people could always do |cvs co projects/myproject| > I think the current state is that the stuff in projects is getting moved > to root, and the xdl dir is getting removed (because it is in the lib > dir). > > ben and i were discussing this, and decided it would be annoying to check > out the projects module and get everyone's project at once... > > > We need a document that describes where things go in CVS. I'm very much > > confused. And as we all know, confusion means something should be written > > down. :) |
From: Kevin M. <ke...@vr...> - 2002-01-22 22:11:27
|
I think the current state is that the stuff in projects is getting moved to root, and the xdl dir is getting removed (because it is in the lib dir). ben and i were discussing this, and decided it would be annoying to check out the projects module and get everyone's project at once... Kevin On Tue, 22 Jan 2002, Chad Austin wrote: > We need a document that describes where things go in CVS. I'm very much > confused. And as we all know, confusion means something should be written > down. :) > > _______________________________________________ > ISUGameDev-devel mailing list > ISU...@li... > https://lists.sourceforge.net/lists/listinfo/isugamedev-devel > -- @--@---@---@----@-----@------@------@-----@----@---@---@--@ Kevin Meinert __ _ __ http://www.vrac.iastate.edu/~kevn \ || \| \ / ` Virtual Reality Applications Center \ ||.-'|--\\ Howe Hall, Iowa State University, Ames Iowa \|| \| \`__, ----------------------------------------------------------- |
From: Chad A. <ae...@ae...> - 2002-01-22 22:03:25
|
We need a document that describes where things go in CVS. I'm very much confused. And as we all know, confusion means something should be written down. :) |
From: Kevin M. <ke...@vr...> - 2002-01-22 20:46:33
|
on the isugamedev.sf.net web site, you'll find a new link called "Project Pages" Under this are links to our club's projects. If yours is not there yet, please take time to add it. We strongly encourage you to host your project page inside your CVS module ==================== CREATE YOUR WEB PAGE ==================== How to create up your CVS module and project web page: - create a CVS module under isugamedev sf.net - mkdir myproject - cd myproject - mkdir doc - echo "my project" > doc/index.html - setenv CVSROOT sub...@cv...:/cvsroot/isugamedev - cvs import myproject yourusername rel ver Basically, if your module is "aki", then create a directory "aki/doc", and put your .jpg and .html content there. then import "aki" into our CVS repos (make sure it is a unique name!).. ================== SUBMIT YOUR LINK: ================== You can then submit a link to isugamedev.sf.net to your new project page like so: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/isugamedev/<your-project-name-goes-here>/doc/index.html NOTE: if your project is already on CVS, then simply add a link to your docs under our links section of isugamedev.sf.net... Thanks! -- @--@---@---@----@-----@------@------@-----@----@---@---@--@ Kevin Meinert __ _ __ http://www.vrac.iastate.edu/~kevn \ || \| \ / ` Virtual Reality Applications Center \ ||.-'|--\\ Howe Hall, Iowa State University, Ames Iowa \|| \| \`__, ----------------------------------------------------------- |
From: Kevin M. <ke...@vr...> - 2002-01-22 20:42:07
|
on the isugamedev.sf.net web site, you'll find a new link called "Project Pages" Under this are links to our club's projects. If yours is not there yet, please take time to add it. We strongly encourage you to host your project page inside your CVS module ==================== CREATE YOUR WEB PAGE ==================== How to create up your CVS module and project web page: - create a CVS module under isugamedev sf.net - mkdir myproject - cd myproject - mkdir doc - echo "my project" > doc/index.html - setenv CVSROOT sub...@cv...:/cvsroot/isugamedev - cvs import myproject yourusername rel ver Basically, if your module is "aki", then create a directory "aki/doc", and put your .jpg and .html content there. then import "aki" into our CVS repos (make sure it is a unique name!).. ================== SUBMIT YOUR LINK: ================== You can then submit a link to isugamedev.sf.net to your new project page like so: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/isugamedev/<your-project-name-goes-here>/doc/index.html NOTE: if your project is already on CVS, then simply add a link to your docs under our links section of isugamedev.sf.net... Thanks! -- @--@---@---@----@-----@------@------@-----@----@---@---@--@ Kevin Meinert __ _ __ http://www.vrac.iastate.edu/~kevn \ || \| \ / ` Virtual Reality Applications Center \ ||.-'|--\\ Howe Hall, Iowa State University, Ames Iowa \|| \| \`__, ----------------------------------------------------------- ---------- Forwarded message ---------- Date: Tue, 22 Jan 2002 13:57:21 -0600 (CST) From: Kevin Meinert <ke...@vr...> To: aki's quest <isu...@li...> Subject: [Isugamedev-quest] new project page, design doc location on the isugamedev.sf.net web site, you'll find a new link called "Project Pages" Under this is a link to our project Aki's Quest, which points to the current checked in copy in CVS: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/isugamedev/aki/doc/index.html This newest version has an image gallery. If you'd like to add images, feel free to check out the CVS module "aki" from our isugamedev CVS server (instructions are linked on the isugamedev.sf.net website). Just edit the aki/doc/gallery.html page and add your .jpg image to the doc directory. Pictures are what will get the creativity flowing. If you don't want to touch CVS, just send me your picture, and I can do it. -- @--@---@---@----@-----@------@------@-----@----@---@---@--@ Kevin Meinert __ _ __ http://www.vrac.iastate.edu/~kevn \ || \| \ / ` Virtual Reality Applications Center \ ||.-'|--\\ Howe Hall, Iowa State University, Ames Iowa \|| \| \`__, ----------------------------------------------------------- _______________________________________________ Isugamedev-quest mailing list Isu...@li... https://lists.sourceforge.net/lists/listinfo/isugamedev-quest |
From: Josh B. <br...@vr...> - 2002-01-22 08:26:59
|
Sorry everyone for sending that erroneous message out, I sent it to the wrong address... cheers Josh |
From: Josh B. <br...@vr...> - 2002-01-22 08:24:31
|
I hadn't heard anythig in a while are we meeting todat at Santa Fe at 7:00? cheers Josh |
From: Ben S. <bs...@vr...> - 2002-01-18 16:44:53
|
oops, i meant that i want the basecode to abstract away GLUT and juggler, not the system abstraction. i'm getting really good at writing emails with poor grammer and paragraph structure. thus, neither VPR or NSPR replace glut or enable me to port a game to C6. ----- Ben Scott President ISU Game Developers Club Treasurer ISU Ballroom Dance Company bs...@ia... On Fri, 18 Jan 2002, Kevin Meinert wrote: > > 2 questions... > what about VPR or NSPR replaces glut? > what about VPR and NSPR enables you to port your game to the C6? > > > > On Fri, 18 Jan 2002, Ben Scott wrote: > > > well, do you think it is needed? also, it would be nice to have it sit on > > top of a system abstraction such as NSPR or VPR (which uses NSPR). pretty > > much i want this so that we can move away from GLUT as our needs grow > > without having to modify the application code. besides, i want to get > > these games to run in C6. ^_^ > > > > cheers, > > ----- > > Ben Scott > > President ISU Game Developers Club > > Treasurer ISU Ballroom Dance Company > > bs...@ia... > > > > On Fri, 18 Jan 2002, Chad Austin wrote: > > > > > > well, i guess i was more thinking of some abstraction on top of GLUT or > > > > VRJuggler that handles initializing the graphics API and contains the > > > > kernel of the application with the draw and update loop. so i guess what i > > > > was thinking was a little higher than the system abstractions provided by > > > > NSPR and VPR ( i don't know what APR is ). > > > > > > > > is that more clear? > > > > > > Yup, thanks. > > > > > > > > > _______________________________________________ > > ISUGameDev-devel mailing list > > ISU...@li... > > https://lists.sourceforge.net/lists/listinfo/isugamedev-devel > > > > |
From: Kevin M. <ke...@vr...> - 2002-01-18 16:39:55
|
2 questions... what about VPR or NSPR replaces glut? what about VPR and NSPR enables you to port your game to the C6? On Fri, 18 Jan 2002, Ben Scott wrote: > well, do you think it is needed? also, it would be nice to have it sit on > top of a system abstraction such as NSPR or VPR (which uses NSPR). pretty > much i want this so that we can move away from GLUT as our needs grow > without having to modify the application code. besides, i want to get > these games to run in C6. ^_^ > > cheers, > ----- > Ben Scott > President ISU Game Developers Club > Treasurer ISU Ballroom Dance Company > bs...@ia... > > On Fri, 18 Jan 2002, Chad Austin wrote: > > > > well, i guess i was more thinking of some abstraction on top of GLUT or > > > VRJuggler that handles initializing the graphics API and contains the > > > kernel of the application with the draw and update loop. so i guess what i > > > was thinking was a little higher than the system abstractions provided by > > > NSPR and VPR ( i don't know what APR is ). > > > > > > is that more clear? > > > > Yup, thanks. > > > > > _______________________________________________ > ISUGameDev-devel mailing list > ISU...@li... > https://lists.sourceforge.net/lists/listinfo/isugamedev-devel > -- @--@---@---@----@-----@------@------@-----@----@---@---@--@ Kevin Meinert __ _ __ http://www.vrac.iastate.edu/~kevn \ || \| \ / ` Virtual Reality Applications Center \ ||.-'|--\\ Howe Hall, Iowa State University, Ames Iowa \|| \| \`__, ----------------------------------------------------------- |
From: Ben S. <bs...@vr...> - 2002-01-18 16:34:03
|
well, do you think it is needed? also, it would be nice to have it sit on top of a system abstraction such as NSPR or VPR (which uses NSPR). pretty much i want this so that we can move away from GLUT as our needs grow without having to modify the application code. besides, i want to get these games to run in C6. ^_^ cheers, ----- Ben Scott President ISU Game Developers Club Treasurer ISU Ballroom Dance Company bs...@ia... On Fri, 18 Jan 2002, Chad Austin wrote: > > well, i guess i was more thinking of some abstraction on top of GLUT or > > VRJuggler that handles initializing the graphics API and contains the > > kernel of the application with the draw and update loop. so i guess what i > > was thinking was a little higher than the system abstractions provided by > > NSPR and VPR ( i don't know what APR is ). > > > > is that more clear? > > Yup, thanks. > |
From: Chad A. <ae...@ae...> - 2002-01-18 14:02:24
|
What's 'basecode'? Is that like NSPR or APR or VPR? If we wanted to take this another step, we could all join the 'kelvin' or 'naikai' SF projects and do the exact same work there. I guess project management would become less than trivial... ;) It wouldn't hurt to look at the Kelvin (used to be called Corncob) wiki and/or source and/or get kepler (dleary) to do design reviews. http://kelvin.sourceforge.net/cgi-bin/ccwiki.pl > i've been thinking about the games we are all working on and how similar > they are in terms of their low-level requirements. as far as i can tell, > we all need: > - a 3d graphics engine > - a cross-platform framework for application basecode > - a scripting engine > - a 2D UI graphics subsystem for menus and such > - a sound engine > - perhaps a physics simulation engine for our 3d games > - a pluggable AI engine > - a virtual file system to simplify loading a file regardless of its > location (be it an archive, the network or on the disk) |
From: Ben S. <bs...@vr...> - 2002-01-18 04:09:19
|
hi all- i've been thinking about the games we are all working on and how similar they are in terms of their low-level requirements. as far as i can tell, we all need: - a 3d graphics engine - a cross-platform framework for application basecode - a scripting engine - a 2D UI graphics subsystem for menus and such - a sound engine - perhaps a physics simulation engine for our 3d games - a pluggable AI engine - a virtual file system to simplify loading a file regardless of its location (be it an archive, the network or on the disk) that was just a small list off the top of my head of reusable components we could create as a club to reuse in all of our games. among other things, developing these components together would reduce the amount of duplicate work we do as a club as well as make it much easier to read each others code and learn from it. so here's what i'm proposing: we should develop this components as a club to speed up the development of our games rather than each write them individually. this will also allow future games to be built more quickly since we won't have to write all the low-level code again. i think this will also give us smaller bites to take rather than trying to swallow an entire game at one time. at the same time we can expand further on the game and architectural designs of our respective games assuming the modules exist. once these modules have been created we can then focus all of our attention on the construction of the gameplay in the games which is where the fun is! if you think this would be useful and you're interested in taking command of the construction of some component, please by all means do so! start emailing this list with design ideas and we can begin to check code into CVS in the lib module. this is where you can get experience with small areas of programming that are required IN EVERY GAME! if anybody's interested, i'm looking into the cross-platform framework for application basecode so we can write applications that will automagically work on any system without having to think about it from an application standpoint. ( yay to us linux freaks! ) ^_^ cheers, ----- Ben Scott President ISU Game Developers Club Treasurer ISU Ballroom Dance Company bs...@ia... |
From: Kevin M. <ke...@vr...> - 2002-01-17 01:15:19
|
uh, ignore the word "inlined"... that didn't make sense. (inlined would work too though it could bloat the code you use it in) On Wed, 16 Jan 2002, Kevin Meinert wrote: > > so... inlined pseudo-COM is good... whew! I've always kind of had that in > mind for DLL stuff anyway. since I like cross platform stuff, C++, and > since I read the Box book (COM book), I've always assumed that we could write our > own limited subset of COM... but have never tried it.. :) seems like the > lightest weight, most expressive (C or C++ syntax), most portable > option... > > does this meet both of our priorities? > > we still haven't settled on using std::io stuff or FILE, std::string stuff or char* > > I'm fine with whatever there, as long as the code doesn't get more brittle > (like if we have to do lots of new and delete). > > NOTE: we can always move the proj from gamedev to a SF.net project. and > the name isn't too permanent. I just wanted to get it up so people could > use it if they wanted... > > > Kevin > > > On Wed, 16 Jan 2002, Chad Austin wrote: > > > > can we use our own com-like thing? > > > > Yeah, we could. COM is a Microsoft-defined ABI (you can write COM objects in VB > > and assembly and they will get along just fine because they know exactly how to > > communicate). So if we somehow guaranteed a COM-compatible ABI (or at least > > something similar), we'd be okay. > > > > > as i understand COM, all you need is: > > > > > > - abstract interface > > > - implementations for that interface > > > - factory to give you those implementations > > > - keep the interface the same (don't change it or you'll break bin > > > compatibility) > > > > > > this would (hopefully?) let us keep a small foot print, and not depend on > > > outside libs (like xpcom, or COM), and avoid the nasty C style OO > > > interface that we'd need to convert to. > > > > > > I know this works with VC++, but will it port to other compilers? > > > > I believe that all Windows compilers at least support an option for > > COM-compatible vtable layouts (it'd be suicide not to support COM), so I guess > > that'll work. > > > > -- @--@---@---@----@-----@------@------@-----@----@---@---@--@ Kevin Meinert __ _ __ http://www.vrac.iastate.edu/~kevn \ || \| \ / ` Virtual Reality Applications Center \ ||.-'|--\\ Howe Hall, Iowa State University, Ames Iowa \|| \| \`__, ----------------------------------------------------------- |
From: Kevin M. <ke...@vr...> - 2002-01-17 01:12:00
|
so... inlined pseudo-COM is good... whew! I've always kind of had that in mind for DLL stuff anyway. since I like cross platform stuff, C++, and since I read the Box book (COM book), I've always assumed that we could write our own limited subset of COM... but have never tried it.. :) seems like the lightest weight, most expressive (C or C++ syntax), most portable option... does this meet both of our priorities? we still haven't settled on using std::io stuff or FILE, std::string stuff or char* I'm fine with whatever there, as long as the code doesn't get more brittle (like if we have to do lots of new and delete). NOTE: we can always move the proj from gamedev to a SF.net project. and the name isn't too permanent. I just wanted to get it up so people could use it if they wanted... Kevin On Wed, 16 Jan 2002, Chad Austin wrote: > > can we use our own com-like thing? > > Yeah, we could. COM is a Microsoft-defined ABI (you can write COM objects in VB > and assembly and they will get along just fine because they know exactly how to > communicate). So if we somehow guaranteed a COM-compatible ABI (or at least > something similar), we'd be okay. > > > as i understand COM, all you need is: > > > > - abstract interface > > - implementations for that interface > > - factory to give you those implementations > > - keep the interface the same (don't change it or you'll break bin > > compatibility) > > > > this would (hopefully?) let us keep a small foot print, and not depend on > > outside libs (like xpcom, or COM), and avoid the nasty C style OO > > interface that we'd need to convert to. > > > > I know this works with VC++, but will it port to other compilers? > > I believe that all Windows compilers at least support an option for > COM-compatible vtable layouts (it'd be suicide not to support COM), so I guess > that'll work. > -- @--@---@---@----@-----@------@------@-----@----@---@---@--@ Kevin Meinert __ _ __ http://www.vrac.iastate.edu/~kevn \ || \| \ / ` Virtual Reality Applications Center \ ||.-'|--\\ Howe Hall, Iowa State University, Ames Iowa \|| \| \`__, ----------------------------------------------------------- |
From: Chad A. <ae...@ae...> - 2002-01-17 01:04:52
|
> can we use our own com-like thing? Yeah, we could. COM is a Microsoft-defined ABI (you can write COM objects in VB and assembly and they will get along just fine because they know exactly how to communicate). So if we somehow guaranteed a COM-compatible ABI (or at least something similar), we'd be okay. > as i understand COM, all you need is: > > - abstract interface > - implementations for that interface > - factory to give you those implementations > - keep the interface the same (don't change it or you'll break bin > compatibility) > > this would (hopefully?) let us keep a small foot print, and not depend on > outside libs (like xpcom, or COM), and avoid the nasty C style OO > interface that we'd need to convert to. > > I know this works with VC++, but will it port to other compilers? I believe that all Windows compilers at least support an option for COM-compatible vtable layouts (it'd be suicide not to support COM), so I guess that'll work. |
From: Kevin M. <ke...@vr...> - 2002-01-17 01:04:46
|
> The way I usually temporarily go about this is defining library::string and > library::list and library::vector classes that are as close to source-compatible you write your own? yuk... i think code reuse is more important than lib size. these really should be inlined. i guess we could use stlport instead, but that might not be good either (whole new set of problems). 200k dll depending on a 400k dll isn't bad or pretentious. more of my philosophy: size doesn't matter, functionality does. I think it's really powerful if a lib gives you an easy interface with as little code to maintain as possible. this usually means more code behind the scenes, which I think is ok, and explains the 200k/400k thing as totally ok. I think it is especially ok when you're only adding on an extra 400k, 400k is small if you consider that you're getting well tested code that you don't have to personally maintain. I'd rather invest my time into the game, and not into string, vector, list code. :( kevin On Wed, 16 Jan 2002, Chad Austin wrote: > > why does it matter if we link against ms DLLs? just because M$ is dumb, > > why should we be? the DLL is easily available, and I think can be > > distributed with the games we make. > > It's not on Win95 machines by default, and therefore adds to the footprint of > the library. For gamedev purposes, I wouldn't mind shipping the MS C++ runtime > as well, but I think it's rather pretentious to make a 200k DLL depend on the > 400k msvcp60.dll for a few simple things like strings and vectors which can > easily be done without. > > The way I usually temporarily go about this is defining library::string and > library::list and library::vector classes that are as close to source-compatible > with the standard C++ library as possible until the runtime support is better, > at which point I'll just typedef the std:: classes. > > > standard C++ is perfectly valid, and is a good thing > > to use. We could convert what I've got over to use read(), open(), and > > close(), but yuk. It doesn't matter a lot to me, but... shouldn't std:: > > be inlined? maybe not the iostreams, huh? I still don't like using > > non-C++ just because of M$ dumbness with their DLLs. Seems like we're > > screwing the elegant-ness of our code just to avoid some restriction their > > compiler imposes on us. do they have a static version of that DLL? that > > could solve it maybe. > > VC++ strings aren't 100% inlined either. You can do static builds, but you > can't statically link to libc++ and dynamically to libc at the same time. :( I > agree, it does suck, but a lot of thing sucks and sometimes it's worth it to > work around them. And ideally, you should have already abstracted out I/O so > you can support UTF-8 and whatnot in Windows. ;) > > > I agree with you, few depends is exactly what I was going for. but I > > don't take that literally. I take it to mean only few _third_party_ > > depends. > > Okay. Either way, it's pretty easy to get away with not using std::string and > std::vector, especially when the benefits are there. > > > my philosohy is, if it comes with the compiler, you can always distribute > > it with the code, no big deal, if it annoys you, choose a different > > compiler.. :) otherwise, avoid other 3rd party libs as much as possible. > > my PCX, SGI, BMP, TGA loaders are all stand-alone. the PNG one I wrote > > needs zlib only... > > If that's your philosophy, that's fine by me. :) But I don't go by that > philosophy. ;) There are other things to take into account, and DLL/download > size (unfortunately) is one of them. > > At least I don't follow the Mozilla C++ coding rules! > http://www.mozilla.org/hacking/portable-cpp.html > > _______________________________________________ > ISUGameDev-devel mailing list > ISU...@li... > https://lists.sourceforge.net/lists/listinfo/isugamedev-devel > -- @--@---@---@----@-----@------@------@-----@----@---@---@--@ Kevin Meinert __ _ __ http://www.vrac.iastate.edu/~kevn \ || \| \ / ` Virtual Reality Applications Center \ ||.-'|--\\ Howe Hall, Iowa State University, Ames Iowa \|| \| \`__, ----------------------------------------------------------- |