Official Penjin Development Thread


PokeParadox

Founder of Pirate Games - Penjin Coder
Staff member
Joined
Dec 8, 2005
Messages
6,603
Age
40
Location
UK
Website
pokeparadox.itch.io
WEBSITE
https://github.com/pokeparadox
YOUTUBE
pokeparadox
fetch.php?media=homebrew:engines:penjin:images:penjinlogo.png

OK... you may or may not have seen the above logo kicking about the forums... and also thought wtf is that about. So I'll tell you.
It's a simple C++ game engine which is supposed to be developer friendly.

What had started as my own set of classes for passing certain modules through university and generally helping me code different things has gradually turned into something quite useful for fellow homebrewers.

I then put my code forward at the start of the PandoraPanic! idea, explained how things worked and after extensive use and feedback from the community, that developed the minigames for PandoraPanic!, Penjin is ready for more general consumption. This is reflected in that PanDjoust and Wandor both chose to use Penjin as a base.

In any case this thread is to further the development of Penjin as a tool for you budding homebrewers that would like to get stuck in with some C++ but not be thrown completely in at the deep end!

So comment on what you would like in terms of features, improvements, etc. And report bugs on the bugtracker.

There is also a programming guide that is very much a work in progress, which you are welcome to help with the documentation!
 

Attachments

  • fetch.php?media=homebrew:engines:penjin:images:penjinlogo.png
    fetch.php?media=homebrew:engines:penjin:images:penjinlogo.png
    3.3 KB · Views: 142
Question: How far is the GL/GLES support? I'm looking to start a 2D platformer/shooter project in the summer when my current project is in a better shape, and I'd like a platform that has easy hardware acceleration on both pandora and desktop. I'm also looking into using Qt's GraphicsView+GLWidget for this, but I consider Penjin's game-oriented design a big plus. Also I haven't quite figured out how to make an effective (frame dropping, precise timing, no event buildup if performance drops) game loop in Qt (If anyone wants to inform me, please start a new thread. This one is for Penjin.).
 
It's been in flux and went on hold when the focus was getting PandoraPanic! ready for launch. I have recently opened up working on GL(ES) side of things and I'm converting code over to ES1.1 specs.
Today I (re)fixed textures loading but I need to handle colour keys better somehow (I currently have the problem that pixel [0,0] is ALWAYS the transparent colour unless the original image has an alpha channel and also that the colour keyed colour can not be changed after initial texture load...).

Also rotations are broken... and are being stubborn to my attempts to fix them.

Basically the short answer is that it kind of works... but still render issues to solve.

I will commit todays code to the repo soon since it did fix many bugs that have crept into the GL code from simply focussing on the SDL backend...
EDIT: Recent changes are in the repo.

EDIT: Also if anyone has any ideas about any of these bugs(the source is on the googlecode page.) please feel free to let me know!
 
Hi,

I can just vouch for the good learning curve of Penjin. a bit over a year ago i knew no c++ whatsoever and still made my first minigame for PandoraPanic, the math game. (recommendation for all people new to c++ and interested in penjin: make a minigame for PP. Even feel free to PM me if you get stuck ; )

But now i am developing Panjoust, turned out to be quite a big project (see the topic in the dev corner for more info). I started using all of the engine elements without knowing their internals, but given the openness, gradually started looking into how things are done and used some of that for my own classes. Now i understand most of the engine as well.

Also, penjin provides the base, but you decide how much you use. The full framework with intro, highscores, and everything else. Or just a couple of files to ease animated sprite handling and some background music.
I just like the quick results during the whole process, that's what kept me going. I'm no master coder, never will be probably, but am doing something i enjoy, and in the meantime creating something hopefully others will enjoy :)


Cheers!

MarkoeZ
 
Request: A basic hello world application or perhaps a C::B template that gives you the minimum required files to make Penjin run.

I've downloaded the latest version of Penjin and PP from SVN, and I can't compile it any longer. Penjin has changed some since the last time I took a look at it. I'll keep on plaing around, but it would be nice with a quick and simple solution to get a Penjin based program running in Pandora, Linux and Windows.
 
Another request: cmake or qmake or some other build configuration. Code::Blocks is nice and all, but I'd rather use the IDE of my choice, which may or may not be no IDE at all :)
 
pstudio said:
Request: A basic hello world application or perhaps a C::B template that gives you the minimum required files to make Penjin run.

I've downloaded the latest version of Penjin and PP from SVN, and I can't compile it any longer. Penjin has changed some since the last time I took a look at it. I'll keep on plaing around, but it would be nice with a quick and simple solution to get a Penjin based program running in Pandora, Linux and Windows.
Well the C::B project file included in the PP SVN makes use of C::B variables, so after you set these it should compile fine without any editing.
Note: Some of these steps might differ on any UNIX system.
Just make sure that:
  • You have a folder named "PenjinBase" with all penjin files in it
  • You have a folder named "Pandora Panic" with all PP related files in it
  • Both folders share the same parent folder (like /projects/PenjinBase and /projects/Pandora Panic)
  • When you open the PP project file in C::B it should ask for environment variables
    • gp2x_sdk - path to the gp2x SDK, only required when you want to compile for it (set it to anything)
    • pandora_sdk - same as above
    • mingw - Windows, path to the MinGW installation
    • libogc - path to the mingw libs path to the Wii SDK files
  • After that all you have to do is clone the gcc compiler, to do that go to Settings->Compiler and Debugger, select the GNU GCC, click Copy and use "MINGW" as the name
  • In case I did not forget anything you should be able to compile PP now
If you want a simple demo application, which shows off the features of Penjin, have a look at the official TestSuite: http://code.google.c.../#svn/TestSuite
It's pretty basic and should not require much effort to setup, in case the included C::B project file does not work.
It shows the use of sprites, states, menu and more


B-ZaR said:
Another request: cmake or qmake or some other build configuration. Code::Blocks is nice and all, but I'd rather use the IDE of my choice, which may or may not be no IDE at all :)

Yeah, would like that, too, I have only used C::B so far, but sometimes it plain sucks on Windows (BSOD and more...), also a makefile might be easier to share and maintain.

foxblock out
 
Last edited by a moderator:
Got it working (thanks fox) but I still think a template of some sort would be nice. Right now I'm copying PP and removing the game specific files.
 
As foxblock mentions, the TestSuite app is pretty much your template. It has a simple Menu which links to small test states. You can check it out from the googlecode repo with the following address.
http://penjin.googlecode.com/svn/TestSuite/

It needs to be positioned so it can see the PenjinBase files too. I do agree that a proper template needs to be created... maybe something that just renders a Red Rectangle or something... But the TestSuite kind of fulfils this purpose.

Just to clarify some of the options have changed in the CBP file... You are required to clone your GNU compiler and call it either LINUX or MINGW - depending on which platform you are using to code on. This was just that C::B calls the default compiler the same thing in both linux and Windows... so depending on the default compiler reduces portability of the project file.

Just to correct foxblock above the "global variables" feature of C::B basically is to let you place your library files where you want on your PC without breaking portability of the project.
Additionally libogc is for Wii and GameCube development and not the location of MINGW libs... If you don't have the toolchains for relevant platforms just set them to "/" or "C:\" just to stop the nag screens :D

a make file is useful I do agree but I just have no experience of creating one and I will not pretend that it is anywhere near my forte. a makefile easily adaptable to each project would be valuable though.
 
PokeParadox said:
Additionally libogc is for Wii and GameCube development and not the location of MINGW libs... If you don't have the toolchains for relevant platforms just set them to "/" or "C:\" just to stop the nag screens :D

Heh, thanks for the clarification I was not too sure about that one either - will edit my post so we don't have false information on here.

foxblock out
 
Last edited by a moderator:
@foxblock: No problem, this why I know documentation needs fleshing out for this! Only so many hours a day etc... but I do keep trying to write a little bit more on the wiki.

GL progress
Well I've been progressing with the GL(ES) backend and now things are mostly rendering ok. rotations are broken, but in my walk to work I figured out what's wrong (I think) so hopefully I can find time to sit and apply my fix soon.
I'm proposing a workaround for the keying issue. For right now I'm thinking to only key out Magenta for PENJIN_GL targets... I think this works for the here and now until a better way is figured out. Alpha channel images will be rendered with full alpha support of course.

Makefile
I've been thinking that it may seem that I do not WANT a makefile... this is not the case, as selfish as it may seem I just don't want to spend time setting one up from scratch...
What I mean to say if you want a makefile for this then let's get a basic template going that we can collab on to get a makefile that works... sound fair?
 
PokeParadox said:
GL progress
Well I've been progressing with the GL(ES) backend and now things are mostly rendering ok. rotations are broken, but in my walk to work I figured out what's wrong (I think) so hopefully I can find time to sit and apply my fix soon.
I'm proposing a workaround for the keying issue. For right now I'm thinking to only key out Magenta for PENJIN_GL targets... I think this works for the here and now until a better way is figured out. Alpha channel images will be rendered with full alpha support of course.
Very nice progress :)

PokeParadox said:
Makefile
I've been thinking that it may seem that I do not WANT a makefile... this is not the case, as selfish as it may seem I just don't want to spend time setting one up from scratch...
What I mean to say if you want a makefile for this then let's get a basic template going that we can collab on to get a makefile that works... sound fair?
If no one has given it a shot in a couple of weeks from now, I might. I'll just need to wrap my last two master's degree courses up first :p
 
Last edited by a moderator:
What about CMake files for building the code base? I don't want to use Code::Blocks and Makefiles are nice and all, but not really robust.

I might create a patch with CMakeList.txt files if I'm allowed to.
 
dflemstr said:
What about CMake files for building the code base? I don't want to use Code::Blocks and Makefiles are nice and all, but not really robust.

I might create a patch with CMakeList.txt files if I'm allowed to.
Oh... I'm just a bit ignorant here, I thought we were walking about makefiles... I'll accept any build methods if it makes life easier for others... but I have even less of a clue with CMake so if you can enlighten me, that would be awesome.
 
Last edited by a moderator:
PokeParadox said:
dflemstr said:
What about CMake files for building the code base? I don't want to use Code::Blocks and Makefiles are nice and all, but not really robust.

I might create a patch with CMakeList.txt files if I'm allowed to.
Oh... I'm just a bit ignorant here, I thought we were walking about makefiles... I'll accept any build methods if it makes life easier for others... but I have even less of a clue with CMake so if you can enlighten me, that would be awesome.
CMake is a cross-platform build tool; you write a CMakeLists.txt file that basically says "I need the SDL headers, the SDL library, OpenAL, etc; find them for me, and once I have them, take these files and produce that library." I'ts VERY easy to use and simplifies cross-compilation and cross-platform compilation; you don't have to care about which compiler to use or choose compiler flags or set up environment variables or anything.

CMake is used roughly as much as "make" is in (big) open source projects, so there's really a big reason to use it as much as you can.

I'll see if I can get time to provide the build files; not this week but maybe the next.
 
Last edited by a moderator:
dflemstr said:
PokeParadox said:
dflemstr said:
What about CMake files for building the code base? I don't want to use Code::Blocks and Makefiles are nice and all, but not really robust.

I might create a patch with CMakeList.txt files if I'm allowed to.
Oh... I'm just a bit ignorant here, I thought we were walking about makefiles... I'll accept any build methods if it makes life easier for others... but I have even less of a clue with CMake so if you can enlighten me, that would be awesome.
CMake is a cross-platform build tool; you write a CMakeLists.txt file that basically says "I need the SDL headers, the SDL library, OpenAL, etc; find them for me, and once I have them, take these files and produce that library." I'ts VERY easy to use and simplifies cross-compilation and cross-platform compilation; you don't have to care about which compiler to use or choose compiler flags or set up environment variables or anything.

CMake is used roughly as much as "make" is in (big) open source projects, so there's really a big reason to use it as much as you can.

I'll see if I can get time to provide the build files; not this week but maybe the next.
Thanks for the crash course, like I said I didn't really know it was any different from traditional makefiles....

Update: Today I finally got rotations to work in GL... and the problem was really really really stupid. (wrong matrix mode was in the init code, preventing me from translating ANYTHING!)
 
Last edited by a moderator:
I have some weird textures problems, but GL backend is generally working better than it was.
I am (re) starting work on a personal project which uses PENJIN_GL primarily, so hopefully focussing on this will help me improve the GL support in Penjin.

PS: I'm not dead, I've just been busy/ill recently.
 
Hey, I've just started messing around with Penjin for my shooter/platformer. I'm not promising anything, I'll see where this idea goes. I checked out the latest development version from SVN and am now trying to get a "Hello World" level program to compile. I'm not using code::blocks, so the whole build process is kind of open and this tinkering might yield some autoconf/automake or similar build files.

(I'm writing this off the top of my head at work while waiting for some test results, so this might not be entirely accurate)
I started out by putting the Penjin source files to a subdirectory named penjin to separate them from the game code. Then I copied _main.cpp, MyGame.cpp, MyGame.h, version.h and userStates.h from PandoraPanic to be used as templates. I found it a bit confusing that the engine depended on headers that are not included in the engine (version.h and userStates,h). I stripped MyGame.cpp to bare minimum for a compile test.

Compiling with no defines produced errors because some files depend on code that require defines, for example Text.h requires the GlyphClass include towork, but the ifdef prevents it from being included. Compiling with -DPENJIN_SDL gives better results, but errors on some cases for missing OpenGL types. Some of these errors are OK, as the source files rely on OpenGL, like the 3D-specific classes, but some like AABB.h, which AFAICT should work with no OGL support use GLFloats or similar, which makes them depend on stuff they don't really need to depend on. I suggest putting an #ifdef PENJIN_3D directive to every OpenGL-reliant piece of code. Well, I'm using the OpenGL acceleration anyway so I guess this isn't a huge problem. I just wanted to do the hello world test with less dependencies.

To reiterate: I'm trying to create a simple application based on Penjin that has a single state which does something like draws a sprite to the center of the screen. My goal is to get this compiled with nothing more than g++. After this I can start working on automatic building with cmake/qmake/automake or whatever. Right now I'm struggling with dependencies (what do I need to build the app), as I can't just compile everything because of the extra OpenGL dependencies. I'm also getting linking errors from stuff beginning with "ov_", which I guess are some Ogg/Vorbis utility library files.

I'll release this example app here as a reference with build instructions when I'm done.

EDIT: After a quick review, I'll probably use CMake
 
Sounds good, a minimum project for new users to get started would be useful indeed (there already is the TestSuite but it's more for showing off features)
I agree with you, some files should be wrapped in ifdefs as I also start with adding all files to my project and then remove file-by-file until it compiles.

For a list of already used defines see the list here:
http://projectinfinity.org.uk/doku.php?id=homebrew:engines:penjin:manual#compilation_modifiers

foxblock out
 
B-ZaR said:
Well, I'm using the OpenGL acceleration anyway so I guess this isn't a huge problem. I just wanted to do the hello world test with less dependencies.

To reiterate: I'm trying to create a simple application based on Penjin that has a single state which does something like draws a sprite to the center of the screen. My goal is to get this compiled with nothing more than g++. After this I can start working on automatic building with cmake/qmake/automake or whatever. Right now I'm struggling with dependencies (what do I need to build the app), as I can't just compile everything because of the extra OpenGL dependencies. I'm also getting linking errors from stuff beginning with "ov_", which I guess are some Ogg/Vorbis utility library files.

Just one big big warning. Currently the GL stuff is not Pandora compatible... a lot of code has been coverted to be ES1.1 compatible but not all instances, also no ES1.1 setup code has been written(to create the window etc).

the AABB, you are right, there shouldn't be any GL specific code in there, more cleanup is required. A lot of the codebase are from early university days or just plain messy. This is one thing I do keep trying to improve.

userStates.h is a user-created file on a per-project basis. It has to list the states available to your project, and this is why it is missing.
version.h is for the Code::Blocks auto-version plugin. This file is generated and modified by C::B itself... you can just copy over the one from PP! and tweak the values contained within...?

Dependencies... ok
for SDL(linux):
`sdl-config --libs`
-lX11 -lXi
-lSDL_ttf
-lSDL_image
-lSDL_mixer
-lSDL_gfx

and for SDL(MINGW)
`sdl-config --libs`
-lmingw32
-lSDL_image
-lSDL_mixer
-lSDL_ttf
-lSDLmain
-lSDL_gfx
-lSDL

and for GL(linux)
`sdl-config --libs`
-lX11 -lXi -lglut -lGL -lGLU
-lSDL_ttf
-lSDL_image
-lSDL_mixer
-lSDL_gfx
-l3ds

and for GL(MINGW)
wow... the only project I have that compile GL on MINGW... all the dependecies are all over the place... I suggest just drop SDL_gfx and add linking to OpenGL stuff :)

I hope this helps somehow...
Oh... also it's been pointed out to me that there is a plugin that converts a CBP file into a makefile here: http://developer.berlios.de/projects/cbmakegen/
 
Last edited by a moderator:
Back
Top