GP32 Mirko Sdk, Coders Needed


mr.mirko

Certified Guru
Joined
Nov 24, 2003
Messages
471
Location
Germany
Website
mirkoroller.de
Hi,

iam searching for help in programming/devving/testing/writing new stuff, for mirkos SDK.

My time is very limited at the moment (i must work on my diploma), and i cant see a time in the (near) future there i get more time to investigate/programm new stuff for my gp32.

There is so mutch to do, rewrite sprite stuff, more sound sampling support, ...

So if someone is a good programmer, knows about gp32, and the hardware very well, and wants to work with my SDK, and extend it. You are invited, to help out.
A later take over, of the complete project, is possible.

I think this is the best thing for the gp32 devving szene.
 
Hi Mr.Mirko,

I also don't have much time (I run a business full time) but I have some sprite routines in development with synchro, unit3, Oankali and a few others that I'm sure all of us would love to see included in your SDK.

The routines would be additional to your current ones (NOT replace them) and would work with pre rotated sprite data. The alpha blending utilises a look-up table for the blending.

Let me know if you would be ok to include this in your SDK, and I/We will provide the code as soon as we have it ready.
 
A bit OT but as you mention Oankali:
Wouldn't it be useful to implement his font and / or directory system into the SDK?
 
Hi Mr.Mirko,

I also don't have much time (I run a business full time) but I have some sprite routines in development with synchro, unit3, Oankali and a few others that I'm sure all of us would love to see included in your SDK.

The routines would be additional to your current ones (NOT replace them) and would work with pre rotated sprite data. The alpha blending utilises a look-up table for the blending.

Let me know if you would be ok to include this in your SDK, and I/We will provide the code as soon as we have it ready.

Yes, this sounds good stuff, if something is ready, send it to me... It will be included...
 
Last edited by a moderator:
I'd like to share my asm scaled / transparent blitting routines. Just tell me where to send them :)
 
A bit OT but as you mention Oankali:
Wouldn't it be useful to implement his font and / or directory system into the SDK?
I think that initially the goal of Mr. Mirko SDK was to provide some low level routines to coders, and my font library is not so low level.
Some time ago, I proposed him to implement in his SDK the first version of my font routines but I think he was to busy at this moment completing his SDK and has his own idea about fonts.

I see no objections if someone wants to make my font library Mr. Mirko SDK compatible, as well as my other libraries. It should be fairly easy.

By the way, I will soon release the new version of the OKF Font Engine with some additions and optimisations.

Oankali.
 
Last edited by a moderator:
Hi Mr.Mirko,

I also don't have much time (I run a business full time) but I have some sprite routines in development with synchro, unit3, Oankali and a few others that I'm sure all of us would love to see included in your SDK.

Yep, I'm with Pea on this, I'll help get these routines ready and get them integrated into your SDK, Mr. Mirko!
 
Last edited by a moderator:
A bit OT but as you mention Oankali:
Wouldn't it be useful to implement his font and / or directory system into the SDK?
I think that initially the goal of Mr. Mirko SDK was to provide some low level routines to coders, and my font library is not so low level.
Some time ago, I proposed him to implement in his SDK the first version of my font routines but I think he was to busy at this moment completing his SDK and has his own idea about fonts.

I see no objections if someone wants to make my font library Mr. Mirko SDK compatible, as well as my other libraries. It should be fairly easy.

By the way, I will soon release the new version of the OKF Font Engine with some additions and optimisations.

Oankali.

I think splitting the SDK to a low level, and a high level part, will make it all very easy.

I also think, if all stuff is included in ONE sdk, it will make devving a lot easier. And the coder can later chose what he wants to use.
Like all low level stuff in : libmirkosdk.a
All high level stuff in : libhigh.a

low level stuff = clockspeed, framebuffer setup, all sound stuff, buttons,fileio, ...
high level stuff = sprite, fonts, drawing of all kind, ...
 
Last edited by a moderator:
I'm not a good coder to help or increase your sdk but perhaps I can made some basic code example?

ah come on! we all saw your stuff, dude!

the thing is, that we need someone in charge (as Mr. Mirko is buys atm) and I think some major decisons are going to happen before the major work starts. (like sprite data and such...) as soon as everything is specified count me in ....
 
Last edited by a moderator:
I'm not a good coder to help or increase your sdk but perhaps I can made some basic code example?

ah come on! we all saw your stuff, dude!

the thing is, that we need someone in charge (as Mr. Mirko is buys atm) and I think some major decisons are going to happen before the major work starts. (like sprite data and such...) as soon as everything is specified count me in ....

The main major descission, who wants to lead/coordinate this stuff ? Its true, iam very busy, so i can not coordinate this ...
So if someone with enought time, and coding skills, wants to take over, he can do it...


Here you can get my last SDK version:
It includes (with bugs) blu+ detecting stuff, and some new directory structures,
so you can add lowlevel and highlevel stuff to seperate diretories.
ftp://mirko.dnip.net/gp32_SDK.tar.gz (only for devvers)
So its very easy to add new font, or new sprite stuff to the lib.addon directory.
 
Last edited by a moderator:
ooh! Could we get long directory name support on the smc lib :D :) :p

Sorry, as for coordination, I can't help there. Providing code is my limit, unless people don't mind very ...slow.... releases...
 
This is a pre 0.92 SDK version

http://home.t-online.de/home/mirkoroller/g...092alpha.tar.gz

Its now completely cleaned up, and i added the blitting/zooming/rotating lib from
CARTIER Matthieu.

Code:
Some notes about performance:
I can give you some numbers, that will give you an idea of the speed improvment regarding the
official free sdk.

So, when you blit 20000 32x32 sprites at 50,50 using:
Zoom -> 2378 ms
ZoomTrans -> 2543 ms
FastTrans -> 1604 ms !!!
GpTrans -> 2573 ms
GpBit -> 1159 ms -> that's why I didn't try to make a quicker one

Note that for zoomed blits, the zoom factor was 1024, so the actual drawed size is 32x32.
In this case, even when zooming on the sprites, it's quicker than the sdk's GpTransBlt.

And, when you blit 20000 16x16 sprites at 50,50 using:
Zoom -> 630 ms
ZoomTrans -> 680 ms
FastTrans -> 418 ms !!!!!!
GpTrans -> 856 ms (lol)
GpBit -> 554 ms (again)

As the functions are optimized for 16x16 chunks, the sdk is much slower here. FastTransBlit
beats the sdk's GpBitblt function, and 32% faster ^^

Thanx to CARTIER Matthieu for this amazing lib.
 
Sorry, as for coordination, I can't help there. Providing code is my limit, unless people don't mind very ...slow.... releases...

I actually tend to be better at co-ordinating than producing a lot of code... I still haven't tested your new functions Pea (although I'd like to get to it tonight before I hit the sack). :)

I wouldn't mind doing some organization, as long as everyone involved is cool with that. ;)
 
Last edited by a moderator:
How do it use the transform feature, i'd like to rotate a point around a centre, then a few points and then drawing lines between them, because i want to make a vector engine.
 
This is a pre 0.92 SDK version

http://home.t-online.de/home/mirkoroller/g...092alpha.tar.gz

Its now completely cleaned up, and i added the blitting/zooming/rotating lib from
CARTIER Matthieu.

Code:
Some notes about performance:
I can give you some numbers, that will give you an idea of the speed improvment regarding the
official free sdk.

So, when you blit 20000 32x32 sprites at 50,50 using:
Zoom -> 2378 ms
ZoomTrans -> 2543 ms
FastTrans -> 1604 ms !!!
GpTrans -> 2573 ms
GpBit -> 1159 ms -> that's why I didn't try to make a quicker one

Note that for zoomed blits, the zoom factor was 1024, so the actual drawed size is 32x32.
In this case, even when zooming on the sprites, it's quicker than the sdk's GpTransBlt.

And, when you blit 20000 16x16 sprites at 50,50 using:
Zoom -> 630 ms
ZoomTrans -> 680 ms
FastTrans -> 418 ms !!!!!!
GpTrans -> 856 ms (lol)
GpBit -> 554 ms (again)

As the functions are optimized for 16x16 chunks, the sdk is much slower here. FastTransBlit
beats the sdk's GpBitblt function, and 32% faster ^^

Thanx to CARTIER Matthieu for this amazing lib.

I can't figure out how to use those blitting functions mentioned. (I can do everything else in the SDK, though).
Any help? I am only getting a black block on a white background when trying to FastSolidBlit a sprite...
 
Last edited by a moderator:
Hi,

iam searching for help in programming/devving/testing/writing new stuff, for mirkos SDK.

My time is very limited at the moment (i must work on my diploma), and i cant see a time in the (near) future there i get more time to investigate/programm new stuff for my gp32.

There is so mutch to do, rewrite sprite stuff, more sound sampling support, ...

So if someone is a good programmer, knows about gp32, and the hardware very well, and wants to work with my SDK, and extend it. You are invited, to help out.
A later take over, of the complete project, is possible.

I think this is the best thing for the gp32 devving szene.

How would you feel at moving the SDK into the devkitPro project?

devkitARM works well with libmirko and there are a number of able programmers helping out. The most recent update has standardised the environment across all 3 major platforms. A windows installer is in progress which should alleviate most of the difficulties experienced by new programmers.

http://devkitpro.sourceforge.net/
 
Last edited by a moderator:
Back
Top