My exact toolset lives at http://www.cs.nmsu.edu/~jeffery/win32/
I have found that which make.exe and which sh.exe are first in the path,
and other irritating and subtle things seem to have to be just right for
everything to be smooth, and once I get them set up I have no problems.
I suspected as much. I set things up as described and downloaded the suggested tools, but ended up with only the rtt.exe and icont.exe files building. I must admit that make is not a tool I'm overly familiar with as for the last 8 years or so I've been working in VB on Windows, and C on an RT embedded system (OS/9) with markedly less sophisticated build tools than *NIX.
Visual C++ should have worked without much trouble if installed correctly
and vcvars32.bat executed and such.
This is the first time I've tried building anything substantial with VC++ 7.1 and I'm considering putting VC++ 6 on my development machine and seeing if that makes a difference. As at one point compilation is choking on declaration of an HGLRC type (which obviously shouldn't be a problem) it's always possible that MS have done something strange with their OpenGL includes. But that said, I ran up a quick example from the GLUT toolkit and that compiles and runs fine, so I'm probably missing something really obvious.
I'd be very happy to work with you through whatever problems you have with
the build process on Windows, and to improve the buildability of my sources.
We want to help more people compiling the sources on more platforms.
I'm planning to build from source on MacOS X and BeOS over the next couple of months, as part of the attraction of Unicon (apart from Icon and OO and DBI) is the idea of write-once-run-everywhere. I know there are people who'd say the same can be achieved with Java, but life is far too short and the runtime far too heavy.
I'm looking at integrating SDL and OpenAL for a project I'm working on.
This is Very interesting. I guess I prefer our own 2D and 3D graphics facilities over SDL for graphics, but of course everyone is free to add whatever they want.
Well my needs are slightly different to those addressed by the standard Icon/Unicon graphics facilities in that I'm looking at developing a networked 3D adventure game, implementing the graphics blits in the background with an SDL thread synced to a fixed (user configurable) frame-rate and probably keeping most of the graphics engine in C as well. I know it probably sounds like a bit of a strange architecture (it's inspired by game development languages like DarkBASIC) but I'm very keen to develop the game-play layer in a decent language whilst still having as high a level of performance as possible. And of course SDL is available pretty much wherever OpenGL is these days. My extremely ambitious long-term goal is to do for 3D gaming what Infocom did for the text adventure >8)
For OpenAL we might want to work with you and make that
part of the language as standard. We have been adding audio support over
the past year, including Voice-over-IP capabilities.
That's something I wasn't aware of. The VoIP capability is something I'd definitely be interested in learning more about, both because it might be useful in the game I'm working on, but also because it occurs to me that (depending on the actual implementation) it could be run off of a web server via cgi with some clever client-side browser scripting making it ideal for use from internet cafes etc...
Once I've had a chance to play properly I'll post the results of my OpenAL and SDL experiments, and if you want to roll them into the main Unicon distro then please feel free to do so.
It appears the loadfunc feature has been implemented for Windows at last
It has, by me, and I made a point to make it possible for the same C code
to be compiled and loadfunc'ed on Windows and on UNIX/Linux, but this was
awhile ago and the code may well have some bitrot on Windows, or only work
under some compilers (say, Visual C++) and need further porting to others.
I bet almost no one has used the loadfunc() on Windows yet, but I could be
surprised. I will certainly assist anyone brave enough to pound on it, but
can't yet guarantee a smooth ride there, and it might need Unicon binaries
built with the non-default (VC++) compiler anyhow.
Well once I get past my current build problems I'll probably be giving this feature some heavy duty testing. I've spent a lot of years wrapping DLLs with VB Classes for WinAPI calls so I can do low-level system programming without needing to resort to C/C++, and I'd like to be able to port some of those designs over to Unicon so I can implement system tray items and so forth. If that doesn't break loadfunc() I suspect that nothing will!
Anyway, I'll have one more bash at building with VC++ 7.1 and if that doesn't work out then I'll try using your toolset again and see if I have any more success!
Eleanor
Senior Software Developer Games With Brains
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Unicon-group mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/unicon-group
