OpenEQ Design

[daeken_bb]

I've started designing the backend of OpenEQ from scratch.

What I have is available at http://home.archshadow.com/~daeken/openeq/src/ in all it's splendour and glory (haha, yea right)

Here's a quick explanation of the purpose of each file:
archive.hpp -- API for Archived file loaders.
fileloader.hpp -- API for 3d file loaders.
3d.hpp -- 3d content structures.
wld.hpp -- Structure for a WLD loader built on top of FileLoader.

I'll work more on it tomorrow.

Please post your comments on it, as a single person designing something this large is a baaaaaaaaad idea :)

Happy Hacking,
Lord Daeken M. BlackBlade
(Cody Brocious)

[Cisyouc]

I assume they are still to be made into linux sources?

[daeken_bb]

I assume they are still to be made into linux sources?

I don't understand what you're asking. Mind elaborating?

[Cisyouc]

You say you are redoing openeq from scratch, will the source be windows compatible as you go along or will we have to port them into windows?

[daeken_bb]

You say you are redoing openeq from scratch, will the source be windows compatible as you go along or will we have to port them into windows?

The source should be largely compatible with windows. I'll need people to test and assist in the porting effort as I have no access to a windows machine for the most part.

[Xorith]

Just tried to compile in MSVC++ Pro 2003 and got massive errors in GL.h for some reason. Will investigate.

[daeken_bb]

Just tried to compile in MSVC++ Pro 2003 and got massive errors in GL.h for some reason. Will investigate.

I severely doubt it's a problem in GL.h itself. It's probably something to do with the include order. Try moving the GL includes about as many things as you can and see if that helps :)

Let me know how it works :)

[Xorith]

I did one better, daeken. I just bypassed MSVC++ all together and went for MinGW.

First problem I ran into was a the obvious network protocol include. I threw this into globala.hpp:


#ifdef WIN32
#include <winsock.h>
#else
#include <netinet/in.h>
#endif /* WIN32 */


That will resolve portability issues with the network.

I had to severely modify the libs in the Makefile


APP=openeq
SF=src/pfs.o src/ter.o src/draw.o src/ddslib.o src/move.o src/matrix.o src/zon.o src/main.o

CC=g++
LINKER=g++
DFLAGS=
WFLAGS=
COPTS=$(WFLAGS) -g
LINKOPTS=-lzdll -lopengl32 -lSDL -LSDL -lpthreadgc1 -lwsock32

all: $(APP)

$(APP): $(SF)
$(LINKER) $(COPTS) $(OBJS) $^ $(LINKOPTS) -o $@

clean:
erase $(SF) $(APP)

%.o: %.cpp
$(CC) -c $(COPTS) $< -o $@


Note to readers:
I downloaded and installed zlib, SDL, and pthreads by hand. MinGW might come with zlib, but I don't think so. I saw libz32.a in the MinGW\lib directory, but I didn't chance it.

The last thing I had trouble with is a conflict with 'Polygon'. Because I can't remember any easier way to fix this, and my editor has a 'Replace all in files' feature, I simply changed Polygon in the source to OEQPolygon. It apparently conflicts with WINGDIAPI.

Now my only hang-up is:


c:/mingw/bin/../lib/gcc-lib/mingw32/3.2.3/../../../libmingw32.a(main.o)(.text+0x
97):main.c: undefined reference to `WinMain@16'
c:\mingw\bin\mingw32-make.exe: *** [openeq] Error 1


I've tried changing main in main.cpp to WinMain and still nothing.

I'll keep ya'll posted on what I find.

-- Xorith

[Xorith]

Alright.

I've tried everything.

I've tried

int WinMain



#include <windows.h>
int STDCALL WinMain


And most other variations.

I've tried including various libraries...

I've tried the -mwindows and -mconsole flags...

It hates me, and I'm tired. :P

-- Xorith

[jbb]

For a windows app you need to replace
int main(int argc, char** argv)
with
int WINAPI WinMain(HINSTANCE, HINSTANCE, int, LPSTR)
{
}

assuming you don't actually care what the parameters are. (And it's c++ so you can leave them out)

[Xorith]

Well, the code uses argc and argv... So using your example, how do I tell the code what file to open?

[jbb]

I ported this today to windows.
It took quite a few minor changes to make it work but nothing difficult. I just hardcoded argc and argv for testing but it would take much to split the command line.

Once a version which is working a bit more fully is done I'll do a windows port and merge it back into the main source.

I used the visual c++ express beta which is freely available and worked very well indeed for this,

[Trumpcard]

Hats off to you daek, you've come a long way

Im proud of you!

[daeken_bb]

Hats off to you daek, you've come a long way

Im proud of you!

Wow, thank you man, that actually means a lot to me :)

I hope you get a chance to play with OpenEQ when we get a little bit more functional hehe

[Trumpcard]

I'd love too. You're being smart and making sure to put the importance on good design concepts, that will really bite you in the butt later on if you neglect the overall design. theres nothing as expensive to fix as a bad design/architecture. Keep it straightforward and simple, and make sure you develop a good modular OO codebase and it'll save you a TON of time later on in terms of maintainability.

Another thing is your asking questions rather than assuming you know the right answers, thats the hallmark of an intelligent man.

[daeken_bb]

I'd love too. You're being smart and making sure to put the importance on good design concepts, that will really bite you in the butt later on if you neglect the overall design. theres nothing as expensive to fix as a bad design/architecture. Keep it straightforward and simple, and make sure you develop a good modular OO codebase and it'll save you a TON of time later on in terms of maintainability.

Another thing is your asking questions rather than assuming you know the right answers, thats the hallmark of an intelligent man.

Yea, it's much easier to fix an implementation than a design. Much more involved to fix a design, too.

I learned long ago that assuming that I know what i'm talking about is a Bad Thing, (TM) especially when working on a project as large as OpenEQ hehe