The collected works of figgles

figgles
Member
Who joined Feb. 4, 2007, 2:48 p.m.
and authored 52 notes
Wrote on the subject of CrystalSpace3D graphics engine on IRIX at April 25, 2008, 11:48 p.m...
I can implement atomic operations in assembly if absolutely needed, but it really is just easier to use MIPSpro intrinsics. I can show you examples of both if you need.

Patrick Baggett
Figgle Software, Inc.
figgles
Member
Who joined Feb. 4, 2007, 2:48 p.m.
and authored 52 notes
Wrote on the subject of CrystalSpace3D graphics engine on IRIX at May 5, 2008, 8 p.m...
Ok, here is a quick hack for you. I haven't compiled this under GCC, but it looks right. Try it out and see if it works.

It uses IRIX's <mutex.h> library, but I couldn't find a compare and swap function, so I had to resort to inline assembly (bleh). It uses GCC's inline asm style, so may not work for MIPSpro.

Anyways, try it out, tell me how it works.

Patrick Baggett
Figgle Software, Inc.
figgles
Member
Who joined Feb. 4, 2007, 2:48 p.m.
and authored 52 notes
Wrote on the subject of CrystalSpace3D graphics engine on IRIX at May 6, 2008, 10:36 a.m...
Man, if I had a week (or two) and CrystalSpace ported, I'd try to port PlanesShift or something. An MMORPG on IRIX.

Actually, I want to be the first to create an MMORPG for IRIX.

Patrick Baggett
Figgle Software, Inc.
figgles
Member
Who joined Feb. 4, 2007, 2:48 p.m.
and authored 52 notes
Wrote on the subject of CrystalSpace3D graphics engine on IRIX at May 8, 2008, 8:09 a.m...
The simple casts are fine really.
Glad it compiles!

Patrick Baggett
Figgle Software, Inc.
figgles
Member
Who joined Feb. 4, 2007, 2:48 p.m.
and authored 52 notes
Wrote on the subject of CrystalSpace3D graphics engine on IRIX at May 11, 2008, 10:15 p.m...
I read that LL/SC pair performed an implicit SYNC, but reading the R10000 processor manual states quite clearly:

"Load Linked and Store Conditional instructions (LL, LLD, SC, and SCD) do not implicitly perform SYNC operations in the R10000 processor."

So I guess it is need for multiprocessor systems with R10000 and variants thereof (R12000, R14000, R16000). Don't know about R8000 or R5000. R5000 is probably the same, R8000 is so weird, who knows what it does...

Patrick Baggett
Figgle Software, Inc.
figgles
Who joined Feb. 4, 2007, 1:48 p.m.
Wrote on the subject of nekoware at May 31, 2008, 2:28 p.m...
I would like an account to build Wings3D / Erlang OTP.

Patrick
figgles
Who joined Feb. 4, 2007, 1:48 p.m.
Wrote on the subject of Wings available for Irix precompiled at June 27, 2008, 2:05 p.m...
So I just compiled Wings3D for MIPS3...

I know someone was interested in its performance on older machines such as R4x00 Indigo2s with IMPACT graphics...so here is my report.

Wings3D 0.99.02
OTP R12B-2
SDL 1.2.13

The test machine is a teal Indigo2 with a R4400 @ 250MHz/2MB L2, 384MB of RAM, and ExtremeGraphics.

Unfortunately, Wings3D performance is terrible with this configuration. Adding a single, 4 polygon pyramid and rotating the camera causes the CPU usage to skyrocket to 100% and the frame draw extremely slowly (interactive FPS, but close to 5-10). I can almost guarantee that this is due to the way the menus/icons are being drawn: textures. As you all probably know, ExtremeGraphics doesn't do texturing in hardware.

I use Maya 5.0 on the same machine, and from playing with multiple thousand polygon models, I can say easily that Maya's performance far, far exceeds Wings3D, and I don't mean that in the way that a professional program written by a company owned by SGI at the time should perform better on SGI hardware versus a generic open source one. Wings3D is written in Erlang and interpreted, yes, but I've found that to be far less of a performance stumbling block even on low end (compared to Octane/Fuel) configs like R10000 @ 195MHz. It is the lack of texturing hardware makes this pretty much unusable unfortunately. Maya uses X11 and overlay planes to do its GUI, and as such, doesn't suffer the performance penalties I'm seeing here.

So, in short, if you want Wing3D on an Indigo, you're pretty much out of luck for getting anything usable. If you are looking for Wings3D on an Indigo2, you will probably want High/MaxIMPACT graphics. The menus on Wings3D aren't what I would consider "texture intensive", so 1MB is actually just fine, though I'm sure that if you are doing texturing in Wings3D, you'll want the full 4MB.

I have tested Wings3D on a purple Indigo2 (R10000@195MHz, 1GB RAM, MaxIMPACT/1TRAM) works great. I have a secondary SolidIMPACT in that machine, but I haven't tried running Wings3D on that monitor.

Patrick Baggett
Figgle Software, Inc.
figgles
Who joined Feb. 4, 2007, 1:48 p.m.
Wrote on the subject of beta: freetype2 2.4.9 at Nov. 3, 2009, 12:19 a.m...
Yay! Even my R5000 180MHz Indy XZ can play this game.*

*-q1 really.

Still pretty cool and neat that the XZ graphics can handle it, even if it is a bit slow.
figgles
Who joined Feb. 4, 2007, 1:48 p.m.
and authored 83 notes
Wrote on the subject of "Unlimited Detail" - new rendering technology at Dec. 19, 2010, 10:17 p.m...
I think it is really funny that the term "voxel" never came up. It seems to be that, but then again, they made it sound sort of like they were trying to show only outer details, e.g. modeling the surface of a rock. In true voxel system, you'd be able to smash the rock apart and see its yummy insides, which is why those systems are so memory intensive -- space is literally subdivided along three axes and a value assigned at each point.
I figure that if you have an arbitrary shape made up of a point clouds, there isn't any reason to store non-visible points (i.e. points which are inside the rock, the previous example), which kind of leads itself to a run-length encoding sort of algorithm, e.g. this column (some X/Y point in 2D space) of points begins at height value A and goes to height value B in space. Since only the points at (X,Y,A) and (X,Y,B) would ever be visible, it wouldn't require memory usage in the same way that storing individual values at every point in the range (X,Y,A) - (X,Y,B) would like a true voxel system....which probably means that majority of the high resolution surfaces are probably static and non-destructible to minimize memory usage.

Considering the 1-point-to-1-pixel statement, it also makes me wonder whether they are trying raytracing. It probably wouldn't be too collide a ray versus a RLE height column...

I'd also like to see what happens when you zoom up to the point that their "point clouds" or "atom" or whatever start to alias multiple pixels -- if they start forming cubes, then I think I've seen enough. I couldn't tell if that happened much, but I'm talking so close that single pebble takes up my entire 1600x1200 screen. I have this funny feeling the detail wouldn't be unlimited .