Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: wojta on February 20, 2003, 01:18:05 pm
-
I've seen some tool which could convert PCX to the .VF files. It's in the source code released by Volition. Unfortunately I haven't required C++ compiler. Has anyone FONTTOOL compiled ?
-
Hi wojta :)
-
It's that time again.
WelcomeBeam, target wojta and AxelWars.
Gunnery control, OPEN FIRE!
(http://members.cox.net/wmcoolmon/images/welcome.gif) (you'd think I'd memorised the link by now, but still have to look it up every single time)
*points rear and left*
exits
*points to heavy artillery*
don't go near the exits.
*points to ventilation ducts*
Shivans
*points to carl*
LoveShivan
-
thanks
-
*hands Axel an anatomically correct Inflate-O-Shivan*
You never know when it might come in handy.
-
Yes, yes, welcome, welcome ;)
Back on topic: I doubt if anyone's ever tried to compile the fonttool. But since I doubt anyone's messed with it, the odds of it working are pretty good...
-
Never mind, it didn't even make it into fs2_open...
If you need it you've gotta get it out of the freespace2_public repository on warpcore... this is the initial release from Volition that Inquisitor put up there, so it hasn't been touched since then...
(I know this still doesn't answer the original post, but I can't imagine why it wouldn't work -- it appears to have no dependencies on any other FS2 code, it's just a converter.)
-
Is it possible to create national characters for use with the Freespace ?
-
Originally posted by wojta
Is it possible to create national characters for use with the Freespace ?
I don't see any reason why not... But I only spent about 10 minutes looking at the font code; don't take this as the final word ;) Look at .../code/graphics/font.* for details.
It looks like there are no restrictions on the number of characters that can be in a font, so theoretically you could have up to 255 in a font, since FS2 uses char * strings, not Unicode nor "wide" (multi-byte) characters.
The only thing that caught me was that a bitmap is allocated for each character in each font, so if there were a huge number of extra characters added, the system might run out of bitmaps, not sure if there's a hard limit on that or not.
In other words, adding Eastern European characters would be OK, putting in all of the Japanese kanji probably wouldn't...
-
Originally posted by penguin
I don't see any reason why not... But I only spent about 10 minutes looking at the font code; don't take this as the final word ;) Look at .../code/graphics/font.* for details.
It looks like there are no restrictions on the number of characters that can be in a font, so theoretically you could have up to 255 in a font, since FS2 uses char * strings, not Unicode nor "wide" (multi-byte) characters.
The only thing that caught me was that a bitmap is allocated for each character in each font, so if there were a huge number of extra characters added, the system might run out of bitmaps, not sure if there's a hard limit on that or not.
In other words, adding Eastern European characters would be OK, putting in all of the Japanese kanji probably wouldn't...
E:\NEW_DIR\fs2_open\code\bmpman\bmpman.h(172): #define MAX_BITMAPS 3500
-
Target? What Target?
-
Originally posted by penguin
(I know this still doesn't answer the original post, but I can't imagine why it wouldn't work -- it appears to have no dependencies on any other FS2 code, it's just a converter.)
It's dependent on code.lib (over 900 files to compile). I have tried to compile it at the school. There are too slow computers. It could take several hours to complete the compilation. I haven't time to do it.
:(
-
Originally posted by wojta
It's dependent on code.lib (over 900 files to compile). I have tried to compile it at the school. There are too slow computers. It could take several hours to complete the compilation. I haven't time to do it.
:(
ugh - good point. Even though fonttool probably only needs a small subset of the objects in code.lib, there's no mechanism to make only those files...
One way to find out what's needed would be to take code.lib out of the fonttool project, and see what symbols are undefined. Then build the object files that contain those symbols, and link them in... Rinse. Repeat.
-
I'll post a compiled 3.5 code lib with this release as well as a tarball of the fs2_open source.
-
Using the original release FontTool will compile if you build it as a debug build. (It's not designed for a release build so you get linker errors about undefined functions due to, I assume, #ifdefs.) I've got one I compiled and could upload somewhere, though it's got the MSVC6 Introductory version nag screen. (BTW, it's a command line program.) Haven't actually tried doing anything with it as I don't really have any files for it to convert and nothing to test the resulting fonts with, but it runs and ought to work. Not sure if it will link right with the fs2_open version of code.lib.
-
(This is a little OT, sorry)
This thread brings up a bigger issue, some stuff that I was discussing in private w/ Maeglamor: as has been noted by a lot of people, there's some spaghetti code here :D
In particular, it's very difficult (to say the least) to extract one component of the fs2 code without including everything... Fonttool is a good example -- all it needs is to be able to read and write bitmaps and font files, but the entire code lib is pulled in (because the file system is tied to localization, bitmaps are tied to the graphics systems, etc...)
Again, no offense to DaveB and Volition -- their goals were different then ours: they needed to get a product out the door; they were paying real money to the developers, artists, testers, etc; they only had one platform they needed to support, etc... And with a commercial product like FS2, maintenance isn't as big a deal: other than squashing post-release bugs, once it's out the door, you never need to look at the code again. Taking all that into consideration, the FS2 code is pretty well organized, and it certainly suited their purposes, and obviously it's a damn fine game.
We live in a different world -- none of us are getting paid to do this (at least I'm not :nervous: ), so we don't have to worry about blowing the budget; we don't have a game publisher breathing down our necks to meet a release schedule (we have Quiz ;)); and it's more important for us to write our code in such a way that someone with less experience can pick up the pieces and do something useful.
Anyhow, this is my (minor) rant. I guess what I'd like to see come out of this (at some point) is to split things up into more manageable modules that can be safely isolated from one another. So if you need PCX utilities, you can just grab those parts.
Components I see that should be isolated from one another:- file management, including VP files -- used by everyone (fs2, FRED, fonttool, etc.)
- bitmap, pcx, tga, etc. utilities (file format manipulators)
- the graphics subsystems; each one -- DirectDraw, OpenGL, software, etc. -- should be independent
- low-level TBL file parser
- higher-level TBL file parsers (weapons, missions, etc.) Each one should be independent
- input stuff (kb, mouse, joystick)
- gameplay stuff -- this actually shouldn't be part of the code lib, as it's only relevant to fs2.exe
- UI
- sound and music
- networking
I'm sure I'm missing some stuff here, but hopefully you get where I'm going with this...
-
There is one advantage to the way Volition structured the code: As long as you don't change any of the files that make up code.lib, you won't have to recompile it every time you make a change to a program that uses it. It only compiles code.lib if it doesn't exist or files it's made of were changed. And all the programs that needed it would share the same library. (And fred2_open can directly use the code.lib from fs2_open, as long as it knows where to find it.) A lot of the code is dependent on things in other files too which would make splitting it up harder and I don't see that it would be of much benefit. (FYI, they didn't just toss the code aside when the game was released, after all the code was originally made for FS1, updated for Slient Threat, and then upgraded to FS2. :) )
For the SCP, the minor programs have been dropped out of the codebase so fred2_open, fs2_open, and any new programs people want to make are all we need to worry about. And both fred2_open and fs2_open use most of the stuff in code.lib. On a file level, the various parts of the game are split up throughout the codebase which can make isolating a particular piece of the program easier, but makes tracing a function back to where it's originally called from take longer.
-
I was thinking it might be good to do some objects, not a complete overhaul but for things like vectors, makeing an object that has oveloaded operators might be a good thing, right now vector math is... quite complex, you have to pick one of four vm_vec functions for any basic vecmath you oftine have to make sure that you don't give destenation vectors are source vector and it would be cool to beable to do things like vec*float rather than just going in and manualy changeing each value in the structure
-
Originally posted by Bobboau
I was thinking it might be good to do some objects, not a complete overhaul but for things like vectors, makeing an object that has oveloaded operators might be a good thing, right now vector math is... quite complex, you have to pick one of four vm_vec functions for any basic vecmath you oftine have to make sure that you don't give destenation vectors are source vector and it would be cool to beable to do things like vec*float rather than just going in and manualy changeing each value in the structure
Yeah, a lot of this stuff could use a more object oriented interface. And before everyone gets all agitated about this, let me qualify that... ;)
I don't mean huge layers of abstraction, polymorphism, etc. Just having constructors and destructors and overloaded methods wouldn't affect performance at all, and would make development a lot easier. Like Bob said, start small with things like the math package.
-
Could anyone send me the compiled Fonttool ?
Why Volition didn't use a truetype font instead of creating the font from bitmaps ? It's my idea of improving FS2_OPEN.
-
Originally posted by wojta
Why Volition didn't use a truetype font instead of creating the font from bitmaps ? It's my idea of improving FS2_OPEN.
It's all about speed, dude ;)
Seriously, there's no need for scalable, hinted, grayscale fonts in a game like FS2 -- since the type is only going to be displayed in one or two pixel sizes ever, rendering bitmap fonts is going to be much faster and simpler.
However, if you wanted to rewrite fonttool -- maybe using the FreeType (http://www.freetype.org/) engine to accept TrueType fonts and generate FS font files -- that would be OK too :D
But I see little reason to incorporate a full TrueType rasterizer within the game...
-
http://fs2source.warpcore.org/fonttool.exe :yes:
-
Thanks.
However, if you wanted to rewrite fonttool -- maybe using the FreeType engine to accept TrueType fonts and generate FS font files -- that would be OK too
Really not now. I'm beginner in C/C++. :(
-
I have downloaded and tried it. It doesn't work.
The main screen appears but it doesn't respond on the keyboard nor the mouse.
This is dumped from the debug window:
Cannot get handle to monochrome driver.
GR_CPU: Family 6, MMX=Yes
D3D Device 0: Direct 3D - Primary Display Driver
Using one that matched Direct3D registry value 'Direct 3D - Primary Display Driver (640x480)'.
Window in debugging mode... mouse clicking may cause problems!
RGB, 5:5:5
ARGB, 1:5:5:5
ARGB, 4:4:4:4
RGB, 5:6:5
RGB, 8:8:8
ARGB, 8:8:8:8
Palettized 8 bpp
Alpha texture format = ARGB, 4:4:4:4
Non-alpha texture format = ARGB, 1:5:5:5
Screen format = RGB, 5:6:5
Direct3D Initialized OK!
TEXTURE RAM: 90860787 bytes (86 MB) available, size divisor = 4
Woohoo! Driver doesn't need square textures!
Textures must be power of 2.
Doesn't support wide surfaces. Bashing max down to 512
Large textures enabled!
Detecting uv type...
Trial #1
Trial #2
Pixel 1 = ef7d , 0
Pixel 2 = ef7d , 0
Rendition uvs: 0
Detecting line offset...
Trial #1
Trial #2
Pixel 1 = 0 , 0
Pixel 2 = 0 , 0
Line offset: 0.0
ANI cursorweb with size 24x24 (25.0% wasted)
No cached palette file
Loading code\fonttool\FontTool.pcx for the first time.
Loading code\fonttool\FontTool.pcx (640x480x16x--)
Error locking surface for bitmap_ex, Access to this surface is being refused because the surface memory is gone. The DirectDraw
Surface object representing this surface should have Restore called on it.
Couldn't get read-only lock to backbuffer for d3d mouse save
Direct3D activate: 0
Direct3D activate: 0
Direct3D activate: 1
Direct3D activate: 1
Couldn't get read-only lock to backbuffer for d3d mouse save
Direct3D activate: 0
Direct3D activate: 0