Login [Register]
Don't have an account? Register now to chat, post, use our tools, and much more.
So after a long overdue major overhaul of the makefiles and some additions to libfxcg I am ready to release PrizmSDK v0.3, termed by some the Cemetech PrizmSDK. The biggest improvement is to the makefiles and build system and it puts me one step closer to a much cleaner setup. Most of the changes are based on the makefiles used by DevkitPro and I plan to move to an installer-based system similar to theirs in the future as well.

The most obvious change visible to the user is the new project directory layout. It is now much cleaner and uses a convenient project layout with specific folders for source files and temp object and such. All the configuration is still in the Makefile in the project directory, which has been cleaned up and commented. All of the dirty work was moved to a separate Makefile in the common folder of the SDK and the project directory shall now house only projects. The end goal is to allow the project directory to lie anyway and have environment variables for where the SDK lies. In the process I also made the makefiles much more cross-platform safe though it might still need more tweaking to get just right.

I still wish to clean up the headers quite a bit more and move to just one header for all the syscalls and have that header include the extra headers with the core typedefs. There is no reason to have the headers split up as they are and I intend to clean that up with the next SDK update, if I donít sneak it into this one. (if you notice filemodtimes change, this would be why)

The next big step will be to include an installer which can optionally grab msys instead of me having to include chunks of msys and cygwin for make and friends to function properly for people without them installed. Please respond with any bugs or issues and I will address them as soon as possible. With how long it took me to complete this release Iím sure I forgot something or made a typo somewhere and the only way I can fix it is if I know about it.

Download:
xz: PrizmSDK-0.3.tar.xz (11M)
gz: PrizmSDK-0.3.tar.gz (42M)
zip: PrizmSDK-0.3.zip (44M)
Congratulations on this release, Jonimus. Smile I hope I was able to offer a positive suggestion or two for the process. I look forward to continued to enjoy your hard work in completing things like Tetrizm and my other ongoing Prizm projects!
atoi disappeared Sad
merthsoft wrote:
atoi disappeared Sad
It's not in libc anymore? Sad
No I had a version of atoi that I had thrown in to the lib while I worked on libc, but it someone disappeared from the latest build
TheStorm wrote:
No I had a version of atoi that I had thrown in to the lib while I worked on libc, but it someone disappeared from the latest build
Good thing that you're using version control, then, and that you'll be able to rescue it for us! Very Happy I still need to organize, clean up, and pack my set of standard graphics routines into something less chaotic one of these days.
well, it seems "memset" in string.h is broken. It'll compile fine, but it doesn't seem to fill memory correctly -- it either fills too much, or too little. My FillData routine, when switched out with memset, worked fine however:


Code:
void*FillData(void*pointer, unsigned char element, int amount){
   void*pointer_ref = pointer;
   for(int i = amount; i > 0; i--) {
      *((unsigned char*) pointer++) = element;
   }
   return pointer_ref;
}


perhaps a typo or something in the memset in the SDK?
Memset is a syscall so if it isn't working correctly then it may not actually be memset, I can double check the syscall number matches simons SDK and if it does then we'll have to assume it was misidentified and go from there.
ah, okay, that would make sense then. Perhaps my data was just completely uninitialized after that memset call then, which would explain the memory changing after different runs.
Sorry for being such a newbie, but how do you draw scrollbars, menus, background images and such? I see it done in a Password discovering add-in, and it has source code, but looks like it was done with miniSDK. Is there a way to do the same with the Prizm SDK?
If its a syscall then it will work with both SDK's, but if it is one of the routines simon added it will not. I tried to port some of them over but his code refused to compile under gcc.
It wouldn't compile using the routine name present in the password extractor code. I don't know if the routines simply don't exist in the PrizmSDK or if they have been renamed to a different name.
Look at what header it is contained in, if it doesn't say _syscalls in it then I most likely don't have it.
Internal error: Segmentation Fault

Hum... AAARGH!

Why? I just have One single 1.58Mo sized filed with only one function...
Eiyeron wrote:
Internal error: Segmentation Fault

Hum... AAARGH!

Why? I just have One single 1.58Mo sized filed with only one function...
I believe there's a limit on the size of add-ins, and I'm pretty sure it's smaller than 1.58MB. Why is your add-in that huge??
151 front sprites...
Don't think about removing -Os from makefile! :p
KermMartian wrote:
Eiyeron wrote:
Internal error: Segmentation Fault

Hum... AAARGH!

Why? I just have One single 1.58Mo sized filed with only one function...
I believe there's a limit on the size of add-ins, and I'm pretty sure it's smaller than 1.58MB. Why is your add-in that huge??
The Physium add-in is slightly larger. We believed that there was a 1 MB limit, but it may have been removed.
Eiyeron wrote:
151 front sprites...
Don't think about removing -Os from makefile! :p
151 sprites at what dimensions and color depth? Also, that sounds suspiciously like it might be a Pokemon game. Very Happy Are you aware that SourceCoder can turn images into arrays for the Prizm?
With the program that I uploaded, and another progs I made for this occasion, I coded ALL the 151 front sprites in 16 bit with palette compression... :p
Eiyeron wrote:
With the program that I uploaded, and another progs I made for this occasion, I coded ALL the 151 front sprites in 16 bit with palette compression... :p
And how big are they? Without palette compression, 1.54MB for 151 sprites (neglecting code) is 0.0101MB = 10.44KB each, or at 2 bytes per pixel, 5347 pixels each. I guess that works out to be 72x72 pixels each, which is actually not that big. Sad Meh.
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 1 of 2
» All times are GMT - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum