GP2X Klimt


I

icurafu

The Hallucinogenic Elf
Joined
Sep 28, 2005
Messages
2,078
Location
Sydney, Australia
Website
gamesreborn.blogspot.com
Hello,

This looks like an interesting project to port to the GP2X. Here is the description...

Klimt is an open-source 3D library, targeted for PDAs and mobile phones. Its API is very similiar to that of OpenGL and OpenGL|ES. We do not claim conformance with these APIs. Nevertheless, Klimt is able to run Coin3D, a large scene-graph base library that builds on top of OpenGL

Klimt is targeted for hardware independence and speed. The only requirement for an actual device to to be able to run Klimt is a 16-bits (RGB565) linear framebuffer. Klimt compiles without any further dependencies. No additional libraries are required for a minimum version..
Click to expand...

So I snoop around the souce and note that it is ported to QTE (Sharp Zaurus).

this is writen to a X11 window, but it would be easier for us to write to the frame buffer directly, or just using SDL.

Here is the build file...

HTML: 
<pre>
#############################################################################
# Makefile for building: libKlimt.so.0.5.1
# Generated by qmake (1.06c) (Qt 3.2.3) on: Tue Jan 13 22:14:18 2004
# Project:  LinuxQTE.pro
# Template: lib
# Command: $(QMAKE) -o Makefile LinuxQTE.pro
#############################################################################

####### Compiler, tools and options

CC       = arm-linux-gcc
CXX      = arm-linux-g++ -DQT_QWS_SL5XXX -DQT_QWS_SHARP -DQT_QWS_EBX -DQT_QWS_CUSTOM
LEX      = flex
YACC     = yacc
CFLAGS   = -pipe $(CFLAGS_EXTRA) -Wall -W $(if $(CFLAGS_RELEASE),$(CFLAGS_RELEASE), -O2) -fPIC  -D_LINUX -DGCC_295X -DQT_NO_DEBUG
CXXFLAGS = -pipe $(CFLAGS_EXTRA) -DQWS -fno-exceptions -fno-rtti $(CXXFLAGS_EXTRA) -Wall -W $(if $(CFLAGS_RELEASE),$(CFLAGS_RELEASE), -O2) -fPIC  -D_LINUX -DGCC_295X -DQT_NO_DEBUG
LEXFLAGS = 
YACCFLAGS= -d
INCPATH  = -I/usr/lib/qt3/mkspecs/qws/linux-sharp-g++ -I. -I../../src/Linux/zsurface -I../../src/Linux -I../../src -I../../include -I$(QPEDIR)/include -I../../src/Base -I../../RasterizerSW565 -I$(QTDIR)/include -I.ui/ -I.moc/
LINK     = arm-linux-gcc
LFLAGS   = $(LFLAGS_EXTRA)  -Wl,-rpath,$(QTDIR)/lib -shared -Wl,-soname,libKlimt.so.0 -Wl,-rpath,/home/ryanr/devel/klimt/bin
LIBS     = $(SUBLIBS) -L$(QTDIR)/lib $(LIBS_EXTRA) -lm -lqte
AR       = ar cqs
RANLIB   = 
MOC      = $(QTDIR)/bin/moc
UIC      = $(QTDIR)/bin/uic
QMAKE    = qmake
TAR      = tar -cf
GZIP     = gzip -9f
COPY     = cp -f
COPY_FILE= $(COPY)
COPY_DIR = $(COPY) -R
DEL_FILE = rm -f
SYMLINK  = ln -sf
DEL_DIR  = rmdir
MOVE     = mv -f
CHK_DIR_EXISTS= test -d
MKDIR    = mkdir -p

####### Output directory

OBJECTS_DIR = .obj/

####### Files

HEADERS = ../../src/Linux/zsurface/ZSurface.h \
  ../../src/Linux/zsurface/ZFont.h
SOURCES = ../../src/klBlitter.cpp \
  ../../src/klEGLSurfaceBuffer.cpp \
  ../../src/Linux/klEGLSurfaceQTE.cpp \
  ../../src/Linux/zsurface/ZSurface.cpp \
  ../../src/Linux/zsurface/ZFont.cpp \
  ../../src/Linux/zsurface/BitBlit.S \
  ../../src/Linux/zsurface/BitBlitKeyed.S \
  ../../src/Linux/zsurface/BitBlitAlpha.S \
  ../../src/Linux/zsurface/Flip.S \
  ../../src/klGlu.cpp \
  ../../src/klGlut.cpp \
  ../../src/klImageConverter.cpp \
  ../../src/klMain.cpp \
  ../../src/Base/klChunkedMemory.cpp
OBJECTS = .obj/klBlitter.o \
  .obj/klEGLSurfaceBuffer.o \
  .obj/klEGLSurfaceQTE.o \
  .obj/ZSurface.o \
  .obj/ZFont.o \
  .obj/BitBlit.o \
  .obj/BitBlitKeyed.o \
  .obj/BitBlitAlpha.o \
  .obj/Flip.o \
  .obj/klGlu.o \
  .obj/klGlut.o \
  .obj/klImageConverter.o \
  .obj/klMain.o \
  .obj/klChunkedMemory.o
FORMS = 
UICDECLS = 
UICIMPLS = 
SRCMOC   = 
OBJMOC = 
DIST    = LinuxQTE.pro
QMAKE_TARGET = Klimt
DESTDIR  = ../../../bin/
TARGET   = libKlimt.so.0.5.1
TARGETA	= ../../../bin/libKlimt.a
TARGETD	= libKlimt.so.0.5.1
TARGET0	= libKlimt.so
TARGET1	= libKlimt.so.0
TARGET2	= libKlimt.so.0.5

first: all
####### Implicit rules

.SUFFIXES: .c .o .cpp .cc .cxx .C

.cpp.o:
	$(CXX) -c $(CXXFLAGS) $(INCPATH) -o $@ $<

.cc.o:
	$(CXX) -c $(CXXFLAGS) $(INCPATH) -o $@ $<

.cxx.o:
	$(CXX) -c $(CXXFLAGS) $(INCPATH) -o $@ $<

.C.o:
	$(CXX) -c $(CXXFLAGS) $(INCPATH) -o $@ $<

.c.o:
	$(CC) -c $(CFLAGS) $(INCPATH) -o $@ $<

####### Build rules

all: Makefile  ../../../bin/$(TARGET)

../../../bin/$(TARGET):  $(UICDECLS) $(OBJECTS) $(OBJMOC) $(SUBLIBS) $(OBJCOMP)  
	test -d ../../../bin/ || mkdir -p ../../../bin/
	-$(DEL_FILE) $(TARGET) $(TARGET0) $(TARGET1) $(TARGET2)
	$(LINK) $(LFLAGS) -o $(TARGET) $(OBJECTS) $(OBJMOC) $(LIBS) $(OBJCOMP)
	-ln -s $(TARGET) $(TARGET0)
	-ln -s $(TARGET) $(TARGET1)
	-ln -s $(TARGET) $(TARGET2)
	-$(DEL_FILE) ../../../bin/$(TARGET)
	-$(DEL_FILE) ../../../bin/$(TARGET0)
	-$(DEL_FILE) ../../../bin/$(TARGET1)
	-$(DEL_FILE) ../../../bin/$(TARGET2)
	-$(MOVE) $(TARGET) $(TARGET0) $(TARGET1) $(TARGET2) ../../../bin/



staticlib: $(TARGETA)

$(TARGETA):  $(UICDECLS) $(OBJECTS) $(OBJMOC) $(OBJCOMP)
	-$(DEL_FILE) $(TARGETA) 
	$(AR) $(TARGETA) $(OBJECTS) $(OBJMOC)

mocables: $(SRCMOC)
uicables: $(UICDECLS) $(UICIMPLS)

$(MOC): 
	( cd $(QTDIR)/src/moc; $(MAKE) )

Makefile: LinuxQTE.pro  /usr/lib/qt3/mkspecs/qws/linux-sharp-g++/qmake.conf 
	$(QMAKE) -o Makefile LinuxQTE.pro
qmake: 
	@$(QMAKE) -o Makefile LinuxQTE.pro

dist: 
	@mkdir -p .obj/Klimt && $(COPY_FILE) --parents $(SOURCES) $(HEADERS) $(FORMS) $(DIST) .obj/Klimt/ && ( cd `dirname .obj/Klimt` && $(TAR) Klimt.tar Klimt && $(GZIP) Klimt.tar ) && $(MOVE) `dirname .obj/Klimt`/Klimt.tar.gz . && $(DEL_FILE) -r .obj/Klimt

mocclean:

uiclean:

yaccclean:
lexclean:
clean:
	-$(DEL_FILE) $(OBJECTS)
	-$(DEL_FILE) *~ core *.core


####### Sub-libraries

distclean: clean
	-$(DEL_FILE) ../../../bin/$(TARGET) $(TARGET)
	-$(DEL_FILE) ../../../bin/$(TARGET0) ../../../bin/$(TARGET1) ../../../bin/$(TARGET2) $(TARGETA)


FORCE:

####### Compile

.obj/klBlitter.o: ../../src/klBlitter.cpp ../../src/klBlitter.h
	$(CXX) -c $(CXXFLAGS) $(INCPATH) -o .obj/klBlitter.o ../../src/klBlitter.cpp

.obj/klEGLSurfaceBuffer.o: ../../src/klEGLSurfaceBuffer.cpp ../../include/klMain.h \
  ../../src/klEGLSurfaceBuffer.h \
  ../../src/klEGLSurface.h \
  ../../include/egl_definitions.h
	$(CXX) -c $(CXXFLAGS) $(INCPATH) -o .obj/klEGLSurfaceBuffer.o ../../src/klEGLSurfaceBuffer.cpp

.obj/klEGLSurfaceQTE.o: ../../src/Linux/klEGLSurfaceQTE.cpp ../../src/Linux/klEGLSurfaceQTE.h
	$(CXX) -c $(CXXFLAGS) $(INCPATH) -o .obj/klEGLSurfaceQTE.o ../../src/Linux/klEGLSurfaceQTE.cpp

.obj/ZSurface.o: ../../src/Linux/zsurface/ZSurface.cpp ../../src/Linux/zsurface/ZSurface.h \
  ../../src/Linux/zsurface/ZFont.h
	$(CXX) -c $(CXXFLAGS) $(INCPATH) -o .obj/ZSurface.o ../../src/Linux/zsurface/ZSurface.cpp

.obj/ZFont.o: ../../src/Linux/zsurface/ZFont.cpp ../../src/Linux/zsurface/ZFont.h
	$(CXX) -c $(CXXFLAGS) $(INCPATH) -o .obj/ZFont.o ../../src/Linux/zsurface/ZFont.cpp

.obj/BitBlit.o: ../../src/Linux/zsurface/BitBlit.S 
	$(CC) -c $(CFLAGS) $(INCPATH) -o .obj/BitBlit.o ../../src/Linux/zsurface/BitBlit.S

.obj/BitBlitKeyed.o: ../../src/Linux/zsurface/BitBlitKeyed.S 
	$(CC) -c $(CFLAGS) $(INCPATH) -o .obj/BitBlitKeyed.o ../../src/Linux/zsurface/BitBlitKeyed.S

.obj/BitBlitAlpha.o: ../../src/Linux/zsurface/BitBlitAlpha.S 
	$(CC) -c $(CFLAGS) $(INCPATH) -o .obj/BitBlitAlpha.o ../../src/Linux/zsurface/BitBlitAlpha.S

.obj/Flip.o: ../../src/Linux/zsurface/Flip.S 
	$(CC) -c $(CFLAGS) $(INCPATH) -o .obj/Flip.o ../../src/Linux/zsurface/Flip.S

.obj/klGlu.o: ../../src/klGlu.cpp ../../include/klMain.h \
  ../../include/gl/gl.h \
  ../../include/gl_definitions.h \
  ../../include/egl_definitions.h \
  ../../include/wgl_definitions.h
	$(CXX) -c $(CXXFLAGS) $(INCPATH) -o .obj/klGlu.o ../../src/klGlu.cpp

.obj/klGlut.o: ../../src/klGlut.cpp ../../include/gl/gl.h \
  ../../include/klMain.h \
  ../../include/gl_definitions.h \
  ../../include/egl_definitions.h \
  ../../include/wgl_definitions.h
	$(CXX) -c $(CXXFLAGS) $(INCPATH) -o .obj/klGlut.o ../../src/klGlut.cpp

.obj/klImageConverter.o: ../../src/klImageConverter.cpp ../../include/klMain.h \
  ../../include/gl/gl.h \
  ../../src/klImageConverter.h \
  ../../include/gl_definitions.h \
  ../../include/egl_definitions.h \
  ../../include/wgl_definitions.h
	$(CXX) -c $(CXXFLAGS) $(INCPATH) -o .obj/klImageConverter.o ../../src/klImageConverter.cpp

.obj/klMain.o: ../../src/klMain.cpp ../../include/klMain.h \
  ../../include/gl_definitions.h \
  ../../src/Base/klMath.h \
  ../../src/Base/klStack.h \
  ../../src/Base/klArray.h \
  ../../src/klEGLSurfaceNative.h \
  ../../src/klEGLSurfaceBuffer.h \
  ../../src/klContext.h \
  ../../src/klWrapper.h \
  ../../include/egl_definitions.h \
  ../../src/klNative_egl.h \
  ../../src/Base/klMatrix.h \
  ../../src/Base/klVec4.h \
  ../../src/Base/klVec3.h \
  ../../src/Base/klVertex.h \
  ../../src/Base/klBase.h \
  ../../src/klEGLSurface.h \
  ../../src/klImageConverter.h \
  ../../src/klDisplayList.h \
  ../../src/klDisplayList_Record.h \
  ../../src/klDisplayList_Commands.h \
  ../../src/Base/klChunkedMemory.h \
  ../../src/Base/klList.h \
  ../../src/Base/klPtrList.h \
  ../../src/klEGLDisplay.h
	$(CXX) -c $(CXXFLAGS) $(INCPATH) -o .obj/klMain.o ../../src/klMain.cpp

.obj/klChunkedMemory.o: ../../src/Base/klChunkedMemory.cpp ../../src/Base/klChunkedMemory.h \
  ../../src/Base/klList.h \
  ../../src/Base/klPtrList.h
	$(CXX) -c $(CXXFLAGS) $(INCPATH) -o .obj/klChunkedMemory.o ../../src/Base/klChunkedMemory.cpp

####### Install

install: all  

uninstall:
</pre>
 
I seem to recall that Klimt is actually already on the GP32, which might make it an even easier port across from there. Its just one more of those libraries that was brilliantly taken over, but no-one used :(.

Except maybe that MGS game that looked brilliant but ran like a slug.
 
could be a good idea to port, but then for which pc port could it be usefull?
 
Well, to be fair, I'm not actually certain the MGS game was actually Klimt, but I was fairly sure it was an OpenGL implementation of 3D ness. I can't, however, remember anything OTHER than klimt that supplies that - Yeti isn't OpenGL, splended though it is, and unless I'm much mistaken, at the time (and iirc now too) the SDL port did not include the OpenGL aspects of SDL.

So it would either be something the guy did himself, or Klimt, in all liklihood.
 
klimt is a big hope for a lot of people I think; shoudl be an easy port, and I doubt it'll run really fast.. but even if it can run a few polys at 20fps on the second cpu, it could rock.. anc certainly make open-gl ports hella-easier :)

Looking forward to see how it works out :)

jeff
 
One thing I really don't quite understand about 3D on the GP32/GP2x. These systems should be able to do some nice stuff.

I remember on the Amiga and ST there were alot of 3D polygon games that ran decent on a 16 bit 7 MHz 68000 with no 3D GPU or floating point. With a 32 bit 166-200 MHz ARM you should be capable of some really nice 3D polygon stuff. Maybe flat shaded but pseudo light sourcing would be good enough. We have become spoiled with textures but alot off cool stuff can be done with simple flat shaded polys. Look at ST/Amiga games like Starglider 1 &2 , Elite, Stunt car, Voyager, Infestation, Virus etc. Now imagine those running much smoother with 4X the polygons. I think what is needed is a clean ARM ASM 3D engine that is opensource. With that alot of nice games could be made. Think Virtua Racing and Virtua Fighter on a handheld, wouldn't be bad. API stuff like openGL is just too big and has too much overhead I think.
 
DaveC posted on Oct 17 2005 at 05:31 PM said:
One thing I really don't quite understand about 3D on the GP32/GP2x. These systems should be able to do some nice stuff.

I remember on the Amiga and ST there were alot of 3D polygon games that ran decent on a 16 bit 7 MHz 68000 with no 3D GPU or floating point. With a 32 bit 166-200 MHz ARM you should be capable of some really nice 3D polygon stuff. Maybe flat shaded but pseudo light sourcing would be good enough. We have become spoiled with textures but alot off cool stuff can be done with simple flat shaded polys. Look at ST/Amiga games like Starglider 1 &2 , Elite, Stunt car, Voyager, Infestation, Virus etc. Now imagine those running much smoother with 4X the polygons. I think what is needed is a clean ARM ASM 3D engine that is opensource. With that alot of nice games could be made. Think Virtua Racing and Virtua Fighter on a handheld, wouldn't be bad. API stuff like openGL is just too big and has too much overhead I think.
​
Click to expand...

Have you seen the "wipeout" project?

http://gp32spain.com/foros/showthread.php?t=22981

Look out the video ( WipeOutGP.zip, on the first post) It runs on a GP32 at 66Mhz. Yes, that's not a typo, sixty six mega hertz
 
Last edited by a moderator:
efegea posted on Oct 17 2005 at 03:45 PM said:
DaveC posted on Oct 17 2005 at 05:31 PM said:
One thing I really don't quite understand about 3D on the GP32/GP2x.  These systems should be able to do some nice stuff.

I remember on the Amiga and ST there were alot of 3D polygon games that ran decent on a 16 bit 7 MHz 68000 with no 3D GPU or floating point.  With a 32 bit 166-200 MHz ARM you should be capable of some really nice 3D polygon stuff.  Maybe flat shaded but pseudo light sourcing would be good enough.  We have become spoiled with textures but alot off cool stuff can be done with simple flat shaded polys.  Look at ST/Amiga games like Starglider 1 &2 , Elite, Stunt car, Voyager, Infestation, Virus etc.  Now imagine those running much smoother with 4X the polygons.  I think what is needed is a clean ARM ASM 3D engine that is opensource. With that alot of nice games could be made.  Think Virtua Racing and Virtua Fighter on a handheld, wouldn't be bad.  API stuff like openGL is just too big and has too much overhead I think.
​
Click to expand...

Have you seen the "wipeout" project?

http://gp32spain.com/foros/showthread.php?t=22981

Look out the video ( WipeOutGP.zip, on the first post) It runs on a GP32 at 66Mhz. Yes, that's not a typo, sixty six mega hertz
​
Click to expand...

Yeah that was pretty cool. I think the GP32 could even do better. It could do more polys at a higher clock speed. For something like a FPS or 3D RPG it could run slower and have more detail. If that could be used for anything and not just wipeout that would be cool. I could see a flight sim using that engine too. I don't know much about it as I don't read Spanish though :(
 
Last edited by a moderator:
DaveC posted on Oct 17 2005 at 05:59 PM said:
efegea posted on Oct 17 2005 at 03:45 PM said:
DaveC posted on Oct 17 2005 at 05:31 PM said:
One thing I really don't quite understand about 3D on the GP32/GP2x.  These systems should be able to do some nice stuff.

I remember on the Amiga and ST there were alot of 3D polygon games that ran decent on a 16 bit 7 MHz 68000 with no 3D GPU or floating point.  With a 32 bit 166-200 MHz ARM you should be capable of some really nice 3D polygon stuff.  Maybe flat shaded but pseudo light sourcing would be good enough.  We have become spoiled with textures but alot off cool stuff can be done with simple flat shaded polys.  Look at ST/Amiga games like Starglider 1 &2 , Elite, Stunt car, Voyager, Infestation, Virus etc.  Now imagine those running much smoother with 4X the polygons.  I think what is needed is a clean ARM ASM 3D engine that is opensource. With that alot of nice games could be made.  Think Virtua Racing and Virtua Fighter on a handheld, wouldn't be bad.   API stuff like openGL is just too big and has too much overhead I think.
​
Click to expand...

Have you seen the "wipeout" project?

http://gp32spain.com/foros/showthread.php?t=22981

Look out the video ( WipeOutGP.zip, on the first post) It runs on a GP32 at 66Mhz. Yes, that's not a typo, sixty six mega hertz
​
Click to expand...

Yeah that was pretty cool. I think the GP32 could even do better. It could do more polys at a higher clock speed. For something like a FPS or 3D RPG it could run slower and have more detail. If that could be used for anything and not just wipeout that would be cool. I could see a flight sim using that engine too. I don't know much about it as I don't read Spanish though :(
​
Click to expand...


The goal of "wipeout" project is to run the game at 60fps with textures and sound and now it almost does this at 80Mhz. Archer, the main programmer, has said that it'll be ported to GP2X as soon as posible. Cross fingers ;)
 
Last edited by a moderator:
First I'd like to see that wipeout project with collisions.

Second I don't understand why people are so into 3D on GP2X. Personally I prefer beutiful 2D over flatshaded 3D. If you can get something like the wipeout project to be fully playable then sure I don't mind the 3D because that can't be done propperly in 2D.
 
Digital Awakening posted on Oct 18 2005 at 11:07 AM said:
First I'd like to see that wipeout project with collisions.

Second I don't understand why people are so into 3D on GP2X. Personally I prefer beutiful 2D over flatshaded 3D. If you can get something like the wipeout project to be fully playable then sure I don't mind the 3D because that can't be done propperly in 2D.
​
Click to expand...

I see that Tiny GL4GP32 was also created for the other famous software opengl renderer.

Did anything cool come of these two? I only like them because I can port opengl to them with a bit of work. I'm hoping that really old openGL games would still work...

or for the game I am porting. Ur-Quan masters, it uses 3D for one point in the game. The planet that you rotate around.
 
Last edited by a moderator:
Klimt looks like a pretty good solution for 3D on the GP2X. I think porting it will be my first project when my hardware arrives in 3 weeks (I'm crossing my fingers there are no more delays).

The thing about software 3D is that your are required to be clever in your game design. If you can limit your geometry and figure out cheap shortcuts for effects without losing quality, your game won't suck.

If you follow the speed guidelines they describe on the Klimt website (e.g. use vertex arrays, use square textures, use culling, etc) and you optimize all of your data in your tools, you can do a lot more than you think.
 
MiniMoose posted on Oct 19 2005 at 07:21 AM said:
Klimt looks like a pretty good solution for 3D on the GP2X. I think porting it will be my first project when my hardware arrives in 3 weeks (I'm crossing my fingers there are no more delays).

The thing about software 3D is that your are required to be clever in your game design. If you can limit your geometry and figure out cheap shortcuts for effects without losing quality, your game won't suck.

If you follow the speed guidelines they describe on the Klimt website (e.g. use vertex arrays, use square textures, use culling, etc) and you optimize all of your data in your tools, you can do a lot more than you think.
​
Click to expand...


Hey thanks. If you port Klimt, I'd be glad to help with some beta testing. I'm sure I'll put it to good use. Partically if it is ported to the SDL opengl libs. :D
 
Last edited by a moderator:
icurafu posted on Oct 18 2005 at 04:34 PM said:
Hey thanks. If you port Klimt, I'd be glad to help with some beta testing. I'm sure I'll put it to good use. Partically if it is ported to the SDL opengl libs. :D
​
Click to expand...

Thanks. I'll post back here after I get my GP2X and have the port project set up on my SVN server.
 
Last edited by a moderator:
You must log in or register to reply here.

Similar threads

H
Problems Making Uae4all
Replies
2
Views
1K
HexDump
H
N
Help Wanted With Makefile
Replies
2
Views
3K
namco
N
M
Open2x Makefile
2
Replies
34
Views
6K
statikeffeck
S
N
Open2x Toolchain - Compilation Problems
Replies
3
Views
2K
senquack
senquack
dgame
.../bin/ld: cannot find -lXinerama compiling MAME 149
Replies
4
Views
5K
dgame
dgame
Back
Top