Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Bobboau on January 12, 2003, 03:23:50 am
-
for the last month or so I've been sort of working on mt own POF editor (http://freespace.volitionwatch.com/blackwater/aurora.zip) designed to maxamise ease of use and ease of expantion, I have managed to finaly get the two main features working (the tab interface and the direct x 8.1 render window) so I'm letting you all look at it,
no, it doesn't realy do much does it?
it will only open "fighter01.POF" and load one bmp texture "Fighter01-01a.bmp" it wont save and you can't even realy edit anything, but it is a begining, and I have learned A _LOT_ about MFC and Direct X and OOP in general, all data types are read but onl a few have there interface's done and none of them are realy implemented, except maybe textures and the header,
any feedback on the basic layout of the main interface
-
Very good. :nod:
Maybe you could make some ModelView add-ons. :D
-
Originally posted by Goober5000
Very good. :nod:
Maybe you could make some ModelView add-ons. :D
That's what I was thinking. Modelview is already pretty efficient as it is, there's no real need for yet another pof editor, but now that you have the skills, you could probably improve it on the points it is lacking?
-
Originally posted by venom2506
That's what I was thinking. Modelview is already pretty efficient as it is, there's no real need for yet another pof editor,
Except for those of us who have problems with the Descent-Network tools. :mad2:
-
hmm... if it'll help any, i'm getting MFC42D.dll not found problem. Something I'm missing?
-
Im also missing MFC42D.dll, whats that file part of?
-
jesus, you lazy slugs :D
http://www.google.com/search?q=MFC42D.dll&ie=UTF-8&oe=UTF-8&hl=da&btnG=Google-s%C3%B8gning&lr=
-
well I'm learning quite a bit, I think it's rendering prety quick considering that it's in windowed mode, so this could translate directly into super fast FS model rendering, I have just gotten it to render with diferent textures for diferent polys (it was actualy quite easy given all the work I did makeing diferent vertex buffers based on texture for each subobject),
it looks like the loading PCX files is going to be a major learning experience to say the least :).
and wouldn't it be nice to have a tool who's creator is actualy still active in the comunity for once
-
Originally posted by Bobboau
well I'm learning quite a bit, I think it's rendering prety quick considering that it's in windowed mode, so this could translate directly into super fast FS model rendering, I have just gotten it to render with diferent textures for diferent polys (it was actualy quite easy given all the work I did makeing diferent vertex buffers based on texture for each subobject),
it looks like the loading PCX files is going to be a major learning experience to say the least :).
and wouldn't it be nice to have a tool who's creator is actualy still active in the comunity for once
Yeah, that would be great:nod:
-
Nice work as usual, Bobboau :nod::yes:
-
another good reason for me not to work with modelview is that it is a huge massavely complex peice of code, of wich I can't open all of (says something about me not haveing a germen code file or something)
-
Originally posted by Bobboau
well I'm learning quite a bit, I think it's rendering prety quick considering that it's in windowed mode, so this could translate directly into super fast FS model rendering
You're certainly right about it being fast, it runs like lightning (well, relatively) on my system...
Originally posted by Bobboau
and wouldn't it be nice to have a tool who's creator is actualy still active in the comunity for once
Yeah, just don't get yourself banned, okay? :D
-
Originally posted by Setekh
Yeah, just don't get yourself banned, okay? :D
:lol: :nervous: :lol:
Nice stuff Bob, I'll try at home later. (P.S. UNI EXAMS ARE STRANGE)
-
yeah, that's true, but that means we won't have a prog that will do everything anytime soon then. At least focus on things modelview can't do first ( like creating engine glows and dock/path ) so I can use them both :)
-
Originally posted by Bobboau
it looks like the loading PCX files is going to be a major learning experience to say the least :).
cant you simply use the FS2 pcx code?
-
You might want to look at the code used by POFView. And maybe next time upload a release build rather then a debug build, getting the right debug dll for a particular system can take a few tries.
-
code for POF view is the same as FS (I'm assuming you are talking about the pof viewer that came with the FS2 source), it's very... compex, the more I look into the PCX format the more I wished I didn't have to write a loader for it
seeing as I havn't even started to write the save code weather it's a debug build or not is't realy important seeing as you cant even use this for anything yet
on the up side I've plugged most of the DX releted memory leaks (there is one leak caused by the dialogs not getting deleted for some reason when you close that I havn't been able to figure out), and I have implemented basic interface for almost all normal data chunks.
soon I'll add some functionality and then the save code,
then it would be worthy of a major pimpage,
I've got some realy good ideas for some cool features that no tool available today has, copy comands, data importing, UV unwraping,
also I'm going to try and get alpha blending for the thrusters and have thrusters that render the same way that the game renderes them (rather than just a simple wire frame)
but for the moment the model only spins around in a little circle that you can't stop, I need to get that user operated too
-
The debug/release build thing right now only changes what DLLs it gets linked with. Some people may not have the debug DLLs so the program won't run unless they search them out and install them. (And those DLLs aren't, strictly speaking, supposed to be distributed to people without the development software I believe.) And, when you get far enough for it to matter, you will want to use tooltips. :) No idea what each of those buttons each thing has would do. If you haven't already, you should fix the label on the texture tab, it still says current dock. Not sure why, but I'm getting a critical error sound, with no error message, when the program quits. (And for Voodoo 3 users, change your color depth to 16-bit before running the program.)
-
there were some memory leaks and a few bad dealocations in that build, the critical error was becase it was trying to delete something that hadn't been alocated, there are still a few leaks but they don't seem too bad for the most part
-
I have updated the zip, it is a relese build, and it is much better at displaying data and user controle for the render window (right and left click on the window to rotate and zoom)
but despite what you may see it has absolutly no saveing capabilities
-
2 Suggestions.
1. Make the mass edit box bigger so it can handle larger numbers. If you load a model with really high, or really long, mass you get that odd scientific notation I think. (The e+ kinda stuff.)
2. The panel label thing for the texture tab still says current dock, which you probably already know. :)
It will load models other then the provided one, though of course it doesn't do the maps. (Or at least, it didn't find the maps for the file I loaded, which doesn't surprise me since it wouldn't have a clue where to look for the maps even if it can get them from vp files, and I don't know if it can do that yet.)
-
it loads BMPs, as I have yet to get a PCX loader
I have just run into a bit of an odd bug, for some odd reason the rotation matrix code just died... I hadn't done anything to it...
illigal instruction when I use D3DXMatrixRotationYawPitchRoll, hmm, well it only shows up when I debug... looks like it's calling, D3DXQuaternionRotationYawPitchRoll insted
-
PCX loading is simple with only 8-bit PCXs in mind.
The PXC file format starts with a 128-byte header, which looks like so:
typedef struct PCXHEADER {
unsigned char Manufacturer,Version,Encoding,BPP;
unsigned short XMin, YMin, XMax, YMax, HDpi, VDpi;
unsigned char ColorMap[48], Reserved, NPlanes;
unsigned short BytesPerLine, PalInfo, HScrSize, VScrSize;
char fill[54];
} PCXHEADER
to quote myself about the file format:
The size of the picture *must* be determined by X/Ymax - X/YMin, since not all PCX savers support HDpi and VDpi, and although I haven't seen a single PCX that didn't have XMin and YMin set to 0, better safe than sorry (Another tiny afterthought: don't forget to add 1 to XMax and YMax (a picture from 0 to 127 is 128 pixels wide)). I also believe that Version should be set to 5, since that's the version used by both 256 color and 24bpp PCXs.
One nasty PCX trap is that BytesPerLine is always even, even if the width of the picture is odd (It seems pretty stupid to keep word alignment in a file, even if it makes sense in memory), but that shouldn't be a problem since texture sizes are powers of two.
PCX files have a simple RLE compression scheme. when you read a byte, if its upper two bits are set to 1 (can be checked by if (byte&0xc0)), then the 6 lower bits (byte&0x3F) are the repeat count of the next byte, which is always a color value. If the byte is less than 0xC0, it's a plain color value.
A loop to convert a compressed PCX data to a char * would look like so:
int counter, i; //to see how far we are in the file, and assuming no C++ style loop variable declarations
char byte1, byte2;
do {
byte1 = fgetc(fileptr);
if (byte1&0xc0)
{
byte2 = fgetc(fileptr);
counter += byte1 & 0x3f;
for(i = 0; i < byte1 & 0x3f; i++)
*dest_buffer++ = byte2;
}
else {
*dest_buffer++ = byte1;
counter++;
}
} while (counter
Note: This code has some faults, starting with it's assuming that the width of the PCX is even (but that won't be a problem unless we go DirectX 9 or OpenGL 2.0), and continuing to not handling 24-bit PCXs, includign hard-coding the stopping point to before the palette (which doesn't exist in 24-bit PCXs), but it should be enough for you to get the basics of unpacking PCXs
-
Well, thanks for the explanation, even when it was not aimed for me.
I even understood it all, so thats how RLE works.
in short:
how many bytes next have the same value.
-
well that'll sove half problem,
don't supose you'd know how to write that to D3DTexture8 (I think that's the name) :)
-
I think you can lock the texture surface (like doing with the back-buffer), and access it like a simple array (As far as I recall, there's a data type D3D_LOCKED_RECT, or something like that. Look at the D3D examples. I'm sure there was something using that in there)
-
is there any chance of someone rewriting this for opengl? it's about time we saw some multiplatform editing tools... LInux/OSX ports of freespace 2 aren't really worth it yet because we have NO editing tools. get us some turret/hardpoint editing tools etc then we can help...
-
well part of the whole point was for me to learn DX and MFC so if someone else wants to take a crack at it fine but I will not, and I am programing this in DX8.1 directly so it would _not_ be easy to change over to another API.
on a brighter note I am makeing considerable progres
don't beleve me click here (http://freespace.volitionwatch.com/blackwater/aurora_and_sorce.zip)
that includes source if anyone wants to see how I'm doing stuff, the code is 90% pure mine, a lot of the DX specific code is from NeXe (http://nexe.gamedev.net) and I had a bit of MFC code taken from someone else for getting my tab selector working
I havn't even touched the PCX loading beond my inital atempt, I think I've gotten the header loading working but nothing else, and untill I figure out how I am going to get it into the proper texture format I probly won't.
it uses vertex buffers and has many diferen't examples for going through the BSP structure
-
OK getting back to PCX loading
how would I figure out the size of the image data, I want to have the header the image and the pallet to all have there own seperate buffers that I can just go
fread(&pcx_file->head, sizeof(char), 128, pcxfile);
int size = calculate_imagesize(pcx_file);
fread(&pcx_file->image, size, 1, pcxfile);
fread(&pcx_file->pallet, sizeof(char), 768, pcxfile);
then just use the pallet entries to directly fill out a corectly formatted bit map during the decompression, If I had some idea how to fill out the texture format this would make things a lot easier.
and fighter01-01a.pcx has a resolution of 223x437 so it has to take into account oddly shaped dimentions
-
Originally posted by Bobboau
OK getting back to PCX loading
how would I figure out the size of the image data, I want to have the header the image and the pallet to all have there own seperate buffers that I can just go
fread(&pcx_file->head, sizeof(char), 128, pcxfile);
int size = calculate_imagesize(pcx_file);
fread(&pcx_file->image, size, 1, pcxfile);
fread(&pcx_file->pallet, sizeof(char), 768, pcxfile);
then just use the pallet entries to directly fill out a corectly formatted bit map during the decompression, If I had some idea how to fill out the texture format this would make things a lot easier.
and fighter01-01a.pcx has a resolution of 223x437 so it has to take into account oddly shaped dimentions
read it once with INT getchar(), it returns one char per read like this, and it returns NULL on EOF.
while(getchar())
{
size++;
}
you then got the total size of the file, and all you need to do then is the math, like this
imagesize=size-(768+128), now use fread.
not sure if you have to close and open it again.
-
Another way to do it is with _findfirst:
int calculate_imagesize(LPSTR pcx_filename)
{
_finddata_t FindStruct;
_findclose(_findfirst(pcx_filename, &FindStruct));
return (FindStruct.size - (768 + 128));
}
-
OK this is what I'm working with right now, it isn't working maybe someone can see were I'm going wrong
struct pcx_head{
char Manufacturer;
char Version;
char Encoding;
char BitsPerPixel;
short Xmin;
short Ymin;
short Xmax;
short Ymax;
short Hdpi;
short Vdpi;
char ColorMap[16][3];
char Reserved;
char Nplanes;
short BytesPerLine;
char filler[60];
};
struct pcx{
pcx_head head;
BYTE *image;
char palette[768];
};
void load_pcx( char *file_name);
void load_pcx( char *file_n){
int x, y, i, size = 0, imgsize = 0;
CString pcx_string;
pcx p_file;
pcx *pcx_file = &p_file;
char file_name[128];
// char head_buf[128];
BYTE *image;
char c;
strcpy(file_name, file_n);
strcat(file_name, ".pcx");
FILE *pcxfile=fopen(file_name, "rb");
if(!pcxfile){
pcx_string.Format("could not load the file %s", file_name);
MessageBox(NULL, pcx_string, "!", MB_OK);
return;
}
while(!feof(pcxfile))
{
fread(&c, sizeof(char), 1, pcxfile);
size++;
if(size > 10000000)return;
}
size -= (768+128);
fclose(pcxfile);
pcxfile=fopen(file_name, "rb");
if(!pcxfile){
pcx_string.Format("could not load the file %s", file_name);
MessageBox(NULL, pcx_string, "!", MB_OK);
return;
}
pcx_file->image = new BYTE[size];
// pcx_file->image = p;
fread(&pcx_file->head, sizeof(char), 128, pcxfile);
fread(pcx_file->image, sizeof(char), size, pcxfile);
fread(&pcx_file->palette, sizeof(char), 768, pcxfile);
x = pcx_file->head.Xmax - pcx_file->head.Xmin + 1;
y = pcx_file->head.Ymax - pcx_file->head.Ymin + 1;
imgsize = x*y;
image = new BYTE[imgsize];
BYTE rep;
int offset = 0;
int j = 0;
//the decompression loop
while(offset <= size){
if(pcx_file->image[offset] & 0xC0){//if the first two bits are set, the next six show how many times to repete the next byte
rep = pcx_file->image[offset++] & 0x3f;
for(i = 0; i< rep; i++){
image[j++] = pcx_file->image[offset++];
if(offset <= size)break;
}
}else{
image[j++] = pcx_file->image[offset++];
if(offset <= size)break;
}
}
// image = new char[(pcx_file->head.BytesPerLine * (pcx_file->head.Ymax - pcx_file->head.Ymin))];
// fread(&image, pcx_file->head.BytesPerLine * (pcx_file->head.Ymax - pcx_file->head.Ymin), 1, pcxfile);
// fread(&pcx_file->palette, sizeof(pcx_file->palette), 1, pcxfile);
// for(i=0;i // image[0];
delete(pcx_file->image);
int X = 0, Y = 1, I=(Y*x)+X ;
pcx_string.Format("pixel %d,%d, pixel no. %d in %s is %d", X, Y, I, file_name, image[I]);
MessageBox(NULL, pcx_string, "!", MB_OK);
// }
delete(image);
fclose(pcxfile);
}
-
what type is BYTE,
an extern *char from somewhere else
or a mistake.
-
it's an unsigned char
-
as far as i can tell, this
while(!feof(pcxfile))
{
fread(&c, sizeof(char), 1, pcxfile);
size++;
if(size > 10000000)return;
}
includes the EOF, because it simply has not gotten to that when the char just before EOF is read. EOF gets read. and then feof(pcxfile) gets set
so your size would be incorrect by +1.
you could do this instead
while(fread(&c,sizeof(char),1, pcxfile))
{
if(size >MAX_FILE_SIZE)
return;
}
it will discontinue the while loop becuase EOF is NULL, and while(NULL) {dostuff} will not dostuff.
btw, i spend a great deal of time studing this for my TBL checker,
sinze i have to read in some 1 mb files.
i do however acces files like this
#include
#include //header for std::ifstream functions
using namespace std;//so i dont have to type std:: all the time
#include //header for usefull c++ type strings
using namespace std;
#include //header for simple output to screen, always much better than printf from ordinary C
somefunction()
{
ifstream myfile(*char)//opens the file
myfile.(AWHOLELOTOFUSEFULL-SUBFUNCTIONS)//mscv6.0 should auto show you the functions.
myfile.getline(aconstchar,READ_MAX,'\n')//terminate read on
encounter newline, and certainly if read_max has been reached
//and it dont care if it is a binary or textfile it is reading.
//also, strings are better than chars, since you dont have to deal with all the rules that ordinary C_strings has.
string mystring ="some words"
string mysecondstring =mystring.substr(6,5);
printf(mysecondstring);// would output "word"
//you can even do this
char[10] junk='1234567890';
mythirdstring = junk;
/*c++ strings auto expands, or contracts according to what they are being setting equal to. something ordinary c-style strings can´t
//no more the, cant convert char[n1] to char[n2] and so on.
why all this, well its always good to know the basics, but coding is moving towards C++, becuase it is more accesible, and decreases production time, you might as well learn c++, rather than punching c.-style stuff that is becomming obselete.
-
well for most string intensive things I use CStrings, most of the char things you see there are actualy just buffers for things I didn't care or didn't know what they were.
-
in any case I must have a fundemental lack of understanding about the file strcusture and/or what I am suposed to do with it, I think it reads the first line corectly...no, no it is't
-
ok this seems to be working better
//the decompression loop
while((offset <= size) && (j <= imgsize)){
if(pcx_file->image[offset] > 192){//if the first two bits are set, the next six show how many times to repete the next byte
rep = (pcx_file->image[offset++] - 192 );
for(i = 0; i< rep; i++){
image[j++] = pcx_file->image[offset];
if((offset >= size) || (j > imgsize))break;
}
offset++;
}else{
image[j++] = pcx_file->image[offset++];
if((offset >= size) || (j > imgsize))break;
}
}
-
yes I think I've got it to decompres into a byte map for even sized textures, wich I can use to generate the textures eventualy,
what do I have to do to get it to read odd sized files, should it ignor the last one or something, what is it there for?
//the decompression loop
while((offset <= size) && (j <= imgsize)){
if(x != pcx_file->head.BytesPerLine){
if(j%x == 1)//if we've hit the end of the line
offset++;//skip one
}
if(pcx_file->image[offset] > 192){//if the first two bits are set, the next six show how many times to repete the next byte
rep = (pcx_file->image[offset++] - 192 );
for(i = 0; i< rep; i++){
image[j++] = pcx_file->image[offset];
if((offset >= size) || (j > imgsize))break;
}
offset++;
}else{
image[j++] = pcx_file->image[offset++];
if((offset >= size) || (j > imgsize))break;
}
}
it seems to work
-
ok now I need some way to load it to a IDirect3DTexture8, anyone want to give me a clue :D
if (D3D_OK != D3DXCreateTexture(g_pDevice, x, y, 1, 0, D3DFMT_A8R8G8B8, D3DPOOL_MANAGED, &d3dtexture))MessageBox(NULL, "texture creation failed", "!", MB_OK);
D3DLOCKED_RECT img_rec;
D3DSURFACE_DESC surf_desc;
d3dtexture->GetLevelDesc(0,&surf_desc);
if(surf_desc.Format == D3DFMT_A8R8G8B8){
//d3dtexture->UnlockRect(0);
if (D3D_OK != d3dtexture->LockRect(0, &img_rec, NULL, D3DLOCK_NOSYSLOCK ))MessageBox(NULL, "lock failed", "!", MB_OK);
//DWORD color;
struct temp_color{
BYTE b;
BYTE g;
BYTE r;
BYTE a;
} *pix;
temp_color temp;
temp.b = 128;
temp.g = 128;
temp.r = 128;
temp.a = 128;
// DWORD *pix;
// DWORD temp = 0;
pix = (temp_color *)img_rec.pBits;
int pitch = img_rec.Pitch;
// pix[0] = 0;
int place = 0;
for(i = 0; i for(j = 0; j place = (i*pitch)+j;
pix[place] = temp;
}
}
d3dtexture->UnlockRect(0);
}
ok, it doesn't seem to be bug enough
-
ok I have gotten it to work, oddly the big problem seems to have been haveing the loading code inside it's own function, I striped it out and moved it into the TXTR loading function makeing it very unpleasent
but the thing I am having truble with, is that it does not like oddly sized texture, it seems partly that the texture size is getting set to a power of two size (not suprizeing) and posably that I am reading the file wrong,
I never got any responce to what I am suposed to do with the extra byte at the end of the each oddly sized row in a PCX
-
you could check the file if it is odd first and then decide which kind of loading function should be called, in order to read the file into a Global array.
you did put typedef struct pcxfile[MAX_FILE_SIZE] into a global space, did´nt you. i think here of you writing that it has problems loading the file from its own function.
what to do with that extra byte, dont use it :).
Now this is Pure speculation.
maybe the size of a PCX file always has to be even, isnt there some sort of GFX card requirement on this. well maybe since you know the size, you simply throw it away.
regarding your loading problems. Only thing i can think of is that you are setting the array or vector in local, and not global space.
-
Originally posted by Bobboau
another good reason for me not to work with modelview is that it is a huge massavely complex peice of code, of wich I can't open all of (says something about me not haveing a germen code file or something)
NOTE: About the German thing, please refer to the readme file included with the source code package. When MS Visual Studio loads a project, it will open all files related to the project. If it gives you something about not able to load everything, then close the project workspace and reload it. It then SHOULD work.
Okay, I haven't been following this thread for a while now, but I just grabbed a copy of MODELVIW32 source myself and took a look at it.
The code itself isn't that complex, given my basic knowledge on C++. Mr. Hermann has done a decent job organizing the code into a presentable state. Some of the additions to it can just be pasted into from Kazan's PCS.
Bobboau, I have seen your POF editor. Despite the many bugs and freeze-ups, I think it's a decent program. And I think that by first working with MODELVIEW32's code, you can integrate a lot of knowledge into your program. The bugs and unfinished features leave MODders of this community in a sense - crippled. The features won't be too hard to integrate with Kazan's code. After all, you'll be doing yourself and the community A FAVOR!
Thanks,
Rampage
-
well the PCX file was being totaly handeled in local space, it reads the file loaded the three chuncks into there respective data sub types (header, pallet and image data) then tranfers the data to the d3dtexture wich the function was given a pointer to, it is entirly about the d3dtexture
anyway I think I found a way to resample the images in a fairly simple manner, after this all I need is to get the saveing stuff to work
-
updated the exe and source (http://freespace.volitionwatch.com/blackwater/aurora_and_sorce.zip)
this now has more functionality than any other model viewer yet made and once I get it to save files (will be done by the end of the weekend) it will be the best POF editor/viewer (no cob converter) ever, and it's still pre-alpha.
there are some things I have planed that will blow everything alse away
it has been designed from the begining to be expandable, and I'm far enough along that it wouldn't be worth starting over with another tool (seeing as I have most of the hard stuff done now),
and most importantly, I want to make my own.
I've made my own resizeing/resampling code, it can handel just about any sized PCX file you through at it, but it will take a _long_ time to load textures that are not powers of 2.
-
Originally posted by Bobboau
the best POF editor/viewer (no cob converter) ever
:wtf: You sure about that? Better than ModelView?
Can it edit paths, dockpoints, and textures? Will it save without crashing?
-
it will, it can't save yet but it will,
and it will alow editing of all POF data, includeing (once I get the basic stuff covered) glow points,
and you may note the cooler graphics, look at thrusters (oh, crap forgot I don't have ani loading yet... just make a thruster01.pcx) and thruster glows, and look at the interface for weapon points and docks, and paths, ect...
I didn't include an interface for every thing available (I set it up so things that don't seem to have any effect like the old "turrets" section in the path data, and docking points are going to be locked at two per dock to help make it easier to make them)
I will like it better, this is my own personal POF editor, built to suit my tastes, so I am abviusly going to think it's the best, but with things like path copying... just think about that for a second, you can now make one path, and copy it, just think how usefull that feature alone will be, and by the time I get done I am going to have a drag and drop interface for everything,
and how would you like a UV unwraper in you're pof editor?
the ability to copy and paste turrets, note I don't mean just the turret data chunk, I am going to try and get actual OBJ2 copying and offset editing so you can do some editing of exsisting POFs without decompileing the model and editing it as a cob!
-
let the fun begings: I'll run it with 3dsmax, and open...mmmh... let se... the ryujin. if it doesn't crash after 5 minutes, you'll get my full support.
edit:
MFC42D.dll
MSVCRTD.dll
MFCO42D.dll
that might be nice to iclude those in the pack, that would save a bit of research.
prog itself:
non-debug mode crashes when you load a pof, but the debug version works fine.
The debug version has half the features the non-debig has, btw...
guess you'd have noticed it soon enough, but in the texture tab, you have "current dock", not "current tex". I grant you that's nitpicking.
ok, there's probably a memory leak somewhere, my ulysses is not rotating anymore and half the buttons have disappeard, just while I was typing there ( was working in background )
correction: the nondebug version works too, what is not working is your ulysses :D
-switiching to full screen then back to windowed mode is a very bad idea: first coz fulscreen doesn't make your ship bigger, second coz after that you can kiss animation smoothness byebye.
the fact that you inversed the mouse axis is frustrating, but therwise you've chosen the bestway for handling rotation with the mouse, I thank you.
some advices: when you select a subsystem or something, make it turn green or another color, bright blue, if it's still visible, is not enough: imagine you're editing the duat with her 74 turrets, zoom out a bit, I dare you to find your turret back ;)
remove that huge geometory that gives the bundaries of the path, it's useless and annoying.
oh... replace the big diamond geometry on the gunpoint with a big dot: on some ships with very cluttered gunpoints, you can't make anything out. A dot bould be nice tho.
about the memory leak thing, it's not a memory leak: the prog obviously doesn't like you change the window, as I said already, it doesn't like to be run in backgroiund either.
positive poins: everything else. you're right, this has the potential for being the best pof tool available.
-
update; first revision of file saveing, I'm sure there are bugs but I don't know of any specificaly,
remember this is pre-Alpha, don't use it on anything important to you
Aurora and source (http://freespace.volitionwatch.com/blackwater/aurora_and_sorce.zip)
just relese Aurora (http://freespace.volitionwatch.com/blackwater/aurora.zip)
Also went through corrected a few interface bugs, and completed all the new/copy/delete buttons for all data types, I will be adding a OBJ2 editor (only data chunk I don't have an interface for, other than INSG, oh, I don't currently (will in the future) support the INSIG chunk in any way, so don't use it on anything with an insignia) with the standard options soon, and then a glow point editor, I am sort of half hartedly documenting the process for adding new data chunks,
And if nobody has seen it, the little yellow/orange blob thing below the tabs is the shield toggle, it is the only render options things I currently have implemented
I'm wondering what the performance of the rendered is on various setups, is everyone getting decent frame rates (mine is a bit slow, especially in the new higher resolution)
Well the only thing the debug does differently than the release is that it has a few different ways of handling things, like rotation, for some reason I was getting an illegal instruction when ever I tried to rotate along more than one axis, after a week and a half of confirming that I was doing it right I just split it so I could move on.
I probably shouldn't even be including the debug version, because it won't likely run right with the debugger on any other machine which is all it's good for, considering all the source is included you could just as easily compile it you're self and it would save on the DL size
The thing with the mouse axis is more that the ship starts out pointing away from you; I could just flip the axis you think is inverted (y I'm guessing)
Actually there is a memory leak, but it is in the destructors for the tab view, which only gets called as the program it being closed, it isn't too bad but I do intend on getting it fixed,
I had left the maximize button in there because I forgot to remove it and I probably will next time I'm doing something in that section of code,
I did the diamond thing because it was the simple way, though I will probably implement something similar to what you want eventually. I like the boundary thing on paths, I guess I could make it optional
And as far as the color for the different points I suppose I could give the selected point a color in opposition to the current selected bank and the non-selected bank half the luminance of the selected bank.
-
nitpicking, when pressing save, and it opens the save dialog,
my button says open, where it should say save :).
on the other points venom mentioned.
i can run this
Minimized, maximized, in the background or behind.
-
Hey Bob, what version of DirectX is this based on? If any.
-
im not bob, but DX 8
#include
-
8.1
-
mmh, this build works very vad for me :(
anyway my videocard is "annoying" right now and might cause the pbs. so feedback in a week.
-
made an update, it should now have more functionality than any other POF editor to date,
though PCS is still needed to compile from a COB, and is probly stabler
I will now add glow points
-
ok now updated with full glow point suport
-
Originally posted by Bobboau
ok now updated with full glow point suport
more nitpicking :).
when you use any of the drop-down menus the 3d window it streches the model a tiny tiny bit from that drop down menus Y axis.
also, i noted now some considerble slowdown, when it runs in the background, or when its minimized.
even as i'm typing this, feels like i'm on terminal again :).
-
Um... Something is wrong. "DX initialisation (Note the Spelling Error) failed". And then "an unsupported operation was attempted".
Overall, I can't run this program. I have a 8 MB video card with DX9. My guess is the dearth in VRAM.
Also, please fix any mistakes in spelling and grammar in the program's diaglogs and interface. Thanks. (This is one reason why I don't use PCS that much. Spelling errors make the program look less complete and professional.)
Rampage
-
spelling mistakes... me? ah, never! :D
I just now updated so you may have gotten a corupted zip, or you could just have some settings diferen't,
actualy there is a bug I was expecting to run into, what color resolution is you're desktop at
-
If you try to run the program on a Voodoo 3 and the Windows display mode is set to 32-bit color you'll get those same messages. Try changing to 16-bit color.
-
actualy I think I just fixed it,
I have made many many updates as HLP has been down, you realy should DL the latest copy
-
Just to let you know bobboau officially has my support and may use POF CS source code if he wants -- i really have to move on
freespace 2 is a great game, i'll peek my head on occasionally to see how the community is doing and occasionally play a mod - but i have moved on to new things
-
[color=66ff00]
*Salutes the german army modder*
Thanks dude. :nod:
[/color]
-
well then, maybe I will try to cut and past some of the cob convertion code, eventualy :)
I just updated, fixed a bug in the dock saveing,
and preleminary draging of data items has been implemented, to move somehting with you're mouse, left click on the render window with the ctrl key down, to return to normal model rotation/zoom mode left click the render window with the ctrl key down again, it will move along the XY plain when you are moveing the mouse with the left button and along the Z axis when you move with the right button down
-
OKAY... Still doesn't work. Still the same messages. WHY?
Rampage