TomorrowPlusX Wrote:All, for your convenience, I've packaged a zip file with built versions of freetype, ftgl, glew, and a recent version of OpenAL ( from CVS ) which works on Panther as well as Tiger. The package includes headers, and is really easy to use.

The archive is here: http://zakariya.net/shamyl/UsefulLibs.zip

By any chance, does anyone have this download? I get a 404 here and would like to get these files again. They are indeed very useful.

TomorrowPlusX Wrote:All, for your convenience, I've packaged a zip file with built versions of freetype, ftgl, glew, and a recent version of OpenAL ( from CVS ) which works on Panther as well as Tiger. The package includes headers, and is really easy to use.

...

The archive is here: http://zakariya.net/shamyl/UsefulLibs.zip

TomorrowPlusX Wrote:OK, as promised, here's a project which includes the text formatting and, in general, the gui api with layout management and so on.

http://zakariya.net/shamyl/WorldEngine.zip

I am just trying to get FTGL and FreeType working myself, and those files of yours sound like just what I need, but the links don't work any more. Any chance to get my hands of these libs and stuff?

(Oh, Nick had said exacly the same thing. Oh well, "me too".)

Here's a project with FTGL and freetype put together into one nice, neat framework. Upon request, if you don't have Tiger, I can make a 10.3.9 compatible Universal Binary build to put up for download as well. I've tested it and it works for both PowerPC and Intel.

Great! I'll try it.

Okay, well let me start out by noting that I am a noob to C programming, and Mac programming in general.

I am writing a 3D fluid engine, and I have already coded most of the basic algorithms, but cannot test them because I have no UI yet.

Because I want to easily port to Windows, I've decided to go with a fully OpenGL UI.

Now, antialiased fonts are somewhat of a rarity in 3D apps, and one I absolutely insist on having.

I would prefer to use FreeType directly (the NeHe tutorial is nice and keeps it straightforward I think) but I cannot seem to get it to work...

I'm assuming that by "add it to your compilation include path," the FreeType2 tutorial means, dragging the folder to the project tree, where my sources and frameworks and targets and whatnot are. So I do that--drag in the include folder.

Then I put the two #include statements at the top of my main.c:

And I get the following error: freetype/freetype.h: No such file or directory.

This is on the line that uses the macro, the second one.

Now I'm poking around in FTGL, and I notice a reference to a libfreetype.a... so I launch the terminal and run Make. Out pops ly libfreetype.a, and I drag it into my project, putting it in the External Frameworks group.

...nothing changes.

So I'm just poking around, and I stumble along the C Language Dialect dropdown... I change it to "ANSI C" instead of "Compliler Default" and viola, the no file error is gone. Yay.

Instead, there are 33 errors happening in OSByteOrder.c... which definately sounds like something I shouldn't mess with.

I am running on OSX 10.3.9 Panther with Xcode 1.2. Any help would be much appreciated.

Thanks in Advance,
-Loki

Too late to know this good forum

Just wondering where I could still download the package
http://zakariya.net/shamyl/WorldEngine.zip

Or TomorrowPlusX, could you please re-activate the dead link? Thanks.

TomorrowPlusX Wrote:OK, as promised, here's a project which includes the text formatting and, in general, the gui api with layout management and so on.

http://zakariya.net/shamyl/WorldEngine.zip
...

tigerking Wrote:Too late to know this good forum

Just wondering where I could still download the package
http://zakariya.net/shamyl/WorldEngine.zip

Or TomorrowPlusX, could you please re-activate the dead link? Thanks.

Actually, I'm finishing up a general purpose library -- sort of like GLUT -- but which provides good timing, fonts, user interface, etc. No 3d code, but a good basecode for "gamelike" OpenGL apps. I'm still finishing it up, but I'll be posting it within the week.

( Basically, I've factored out the basecode I used in WorldEngine so I can easily re-use it elswhere. It's a little like an extension of OneSadCookie's GameShell, but with math, resource management, etc. It's C++, that may or may not be a plus given your "religion". )

That's really great and I am just using C++.

I will be right here waiting ...

TomorrowPlusX Wrote:Actually, I'm finishing up a general purpose library -- sort of like GLUT -- but which provides good timing, fonts, user interface, etc. No 3d code, but a good basecode for "gamelike" OpenGL apps. I'm still finishing it up, but I'll be posting it within the week.

( Basically, I've factored out the basecode I used in WorldEngine so I can easily re-use it elswhere. It's a little like an extension of OneSadCookie's GameShell, but with math, resource management, etc. It's C++, that may or may not be a plus given your "religion". )

TomorrowPlusX Wrote:Actually, I'm finishing up a general purpose library -- sort of like GLUT -- but which provides good timing, fonts, user interface, etc. No 3d code, but a good basecode for "gamelike" OpenGL apps. I'm still finishing it up, but I'll be posting it within the week.

( [...] It's C++, that may or may not be a plus given your "religion". )

Yay!

(And an extra "Yay!" to please the forum software minimum message length )

I'm polishing up sample code using the framework ( "Simple Game Framework", or SGF.framework ) so I can hammer out weak spots in the api.

Right now I've got 5 or 6 demos using the framework demonstrating timers, textures, complex layouts, logging facilities, etc. I'm finishing up a port of my GLUT GLSL water renderer with a nice overlay gui for controlling the shader parameters.

The framework provides:
- simple path management
- ref-counted texture management, so multiple loads of the same texture give you a boost::shared_ptr to one instance
- render to texture using FBOs and PBuffers
- A host of useful GLSL classes, which have allowed me to clean up hundreds of lines of GLSL to a few dozen in some cases.
- A whole GUI api with layout management, fonts, etc etc. Uses SlotSig for signal/slot event delegation.
- reasonably decent keyboard support -- works for my American English charset...
- a simple screenshot class which writes out PNGs or JPEGs.
- basic math, with vec2, vec3, vec4, mat4, plane, quaternion math -- adpated from a demo by humus ( http://www.humus.ca )
- frustum and AABB classes for simple visibility determination
- simple camera class
- templated spring and accumulator classes for nice motion and smoothing.
- mersenne twister random number engine
- string operations, since std::string, while excellent, is lacking in places
- simple timer class using signal/slot approach for callbacks

Probably some more. Basically, stuff I use all the time in my own work, which deserved its own framework.

I've also written doxygen comments and have html API documentation.

So, when I'm done with the demos -- they help me clean up and test the API pretty well -- I'll post this in the announcements forum. Obviously, I'll provide full source code and everything. I'd appreciate it, when I post this, if people with intel machines can verify that it works

Any exciting news ?

Basically everything's in place, but I'm working on making my user-interface code work in a render-to-texture situation, so you could have a computer screen in game -- in 3d -- which you can interact with, sort of like in Doom3.

Also, I know for a fact it blows up on intel... I'll need people's help to get it working there

Beats me why it blows up, it's vanilla C++ written over Cocoa. I don't do anything hairy, or ill-advised.

Things to watch out for on Intel

* byte order -- any time you do I/O, including file, network, and AGP/PCIe, you have to be careful. Note that some texture formats (RGBA, UNSIGNED_BYTE) are endian-independent, and others (RGBA, UNSIGNED_INT_8_8_8_8) are not.

* integer division by zero -- n / 0 is 0 on PPC, but you'll crash with EXC_i386_DIV on Intel. Floating-point division by zero is always OK (you'll get +/- INF on both platforms).

Yeah, I'm actually a little concerned about byte ordering in my texture code. I dropped Quicktime for using libPNG directly ( I just can't stand the deprecation warnings... ), and I will I'm certain find endian mistakes.

Regarding division by zero, that's interesting and may in fact be the bug -- since it crashed under rosetta, too, which would make sense if it's a div by zero. Oh, x86, how I missed you.

Rosetta emulates PowerPC correctly, including giving zero for integer division by zero. In any case, it'll always be obvious from a crash report if that's the case (EXC_i386_DIV). If your application doesn't run in Rosetta, it could be a Rosetta bug, or more likely, a bug in your application that happens not to show up on your machine/OS

As always, for an EXC_SIG_SEGV or EXC_BAD_ACCESS, the first stop is Guard Malloc, to see if you crash somewhere different.