JF make 259
JF Nav
JF Nav
Creation Date: 2003-02-18
Today I spent the morning (9:30 AM - 3 PM) porting AS3D to GLUT. I found that it was possible, but not positive. I downloaded the GlutMaster pseudo-library interface for glut. I figured it out in less than half an hour, it was really simple. So I added it to AS3D as version 0.11.0. It just would not compile. gcc works fine, but ld does not. Why? Why?! It took me four hours to find out. Ugh. So I finally have the brilliant idea to compile it invertly: take a working GLUT sample and add a single small part of AS3D. Same problem. So then I check the makefile. The makefile isn't compiling my AS3D class. I look in the problem in the AS3D and what do you know, it's not compiling the glutMaster. Duh, that would give an error. So I spend another half hour finding out that a quirk in KDevelop made it not compile it due to directory structure and file extention (glutMaster.c++ instead of glutMaster.cpp). Very silly, indeed. So then I have it running, right? No. Glut is built incorrectly for my program. While I do use a mainloop, I have multiple levels of returns due to my correct* use of C++. It is event-based where my program is object based. It controls the loop with this function called glutMainLoop. If you want to sidestep glut, there's a website with instructions on how to hack it. I don't want to hack glut. Sure, you may find it fine, and if I really wanted to use glut, I would, but I do not. You see, I checked a bit of source code for SDL on NeHe and I'm going to use it. Thanks Jeff and Ti Leggett! You might remember that I used NeHe source code for my Milkshape Model Loader and my Linux GLX base code (which I am now rewriting in SDL).

Update: 5 PM.
I have just spent the rest of the afternoon (3-5 PM) porting AS3D to SDL. It works. glX and wGL both have very simple font interfaces, so I added both with the good ol' #ifdef __WIN32 #else #endif preprocessors. Cone3D uses bitmap fonts. I'm against texture fonts since I recently switched from my own implementation of texture fonts and tried the glX geometric bitmapped fonts. I think you would be if you did too. So now that everything is ported to SDL, how long until I get a working Windows version? I haven't compiled AS3D under windows so I have no idea if it works, but it just might with a little hax0ring. Man, that'd be sweet, huh? You non-Linuxers could actually use AS3DMD and make mangas until the cows come home. I have to download, install, and mess around with MinGW before I can port it. I have a copy of MS VC++ 6.0 and it's technically not pirated (paid for but not by me), but I don't want to become the guy who gives up Open Source whenever it's easier to do nothing than to do something.

What can I say about porting someone's program? If you are native Linux, porting is easy. It (for better or worse) even becomes a priority in many Linux programmers minds. It should at least be a factor in Windows programmer's minds, but very rarely is. If you've never used Linux, thinking about porting from Windows is an impossible task. Porting a DirectX8 or DirectX9 (both _very_ C++/C# based) to OpenGL and glut or SDL (_very_ C based) seems like a dauting task. Why would someone do something so foolish? Speed, portability, and diverse uses. Writing an industrial program for windows is like (bad analogy-->) using paper towels to blow your nose: if it works at all, it won't for long and will definately not work well. So how did I port my DirectX 8.1 program to OpenGL Linux, portable to Win32? This is the lesson. I worked on my programming skills and techniques. I made my DirectX work. Then I got a Linux distro working. Then I used Linux tutorials from NeHe to get a small engine running in Linux. That builds upon itself. Then I used my mad programming skills to copy and paste the OS-independent source from the old to the new. I made a few structural changes (bones are now joints which are no longer matrix-skinned*) (which I would have done anyway if I kept it in Windows) and now it's fully ported. It took me two hours to take very Linux-dependent source code and switch it to SDL (note the only reason that it was so easy was because my Linux-dependent code was originally ported from SDL code ^_^). If your coding is good and is 90% copied from stable tutorials, you should have no problem porting to SDL. The 3D engines these days are very nice. The tutorials are all out there. All that's left is the easy part: writing a game/program. You need a scene hierarchy and you need control over it. You need to parse your mouse and keyboard into commands. You need 3d models and animations (get a degree in digital graphics). You need some type of scripting or simple AI (get a degree in computer science). You need collision detection (get a degree in physics). Then I assume you've already written endless specs and scripts for the game. Then you have stuff going. If you don't want to spend six years getting three degrees, I can suggest getting a few books and putting thousands of hours and several years into it. I've spent four years getting my physics degree. I'm only able to do the programming because I've spent two of those years (and countless years of my youth) seriously learning programming. The art is coming in last place naturally if you check out JF. Some people say that my style is not good. I say heck with it. The computer makes up for my lack of talent.

*The one complaint I have about OpenGL is that it lacks GPU independent hardware-based matrix skinning. It is much slower due to this. If I want to do matrix skinning, I have to mess around with the NVSDK and vertex programs. I've decided that I will do it when I start work on Hack Mars code (ie. Collision detection for which I am currently deriving the physics formulas). Update: 11:32 PM:
This is less like a webcomic and more like a weblog, huh? Well, I just finished upgrading Terrain Works to version 0.11 aka. sdl. It took about thirty minutes which is reasonable considering I changed a lot of stuff. It's kinda amazing how deep unportable stuff can get. In the AS3DApp file, it used XK_symbols for keys and I had to rename them SDLK_symbols. Really hard, huh? I'll upload both of them to the official AS3D website. I'm going to call them BETA for about a week or so until I test them both at their limits. Actually, right now the screenshot is giving a segfault which suxx0rs. Thankfully I have KDevelop so I can debug it very easily. It'll be debugged before I post it.

Lesson: fclose(NULL); creates a SegFault. So if you go: asd_out = fopen("/not/a/frigging/directory/file.png", "w") fprintf(asd_out, "I suck. Two for a dolla.n"); fclose(asd_out); in any similar terms, you will get a segfault or worse. If you are forced to use C instead of C++ , Instead do this: asd_out = fopen("/not/a/frigging/directory/file.png", "w") if(asd_out) { fprintf(asd_out, "I suck. Two for a dolla."); fclose(asd_out); } else printf("I suck. Two for a dolla.n"); And you'll probably want to use language that you wouldn't be embarrassed for your grandma to see if you fear the FCC more than I do.

JF Nav
Home Characters Making Of Technical Mail News Links |< First < Prev Next > Latest >|  bandwidth version Goto Scene