Omnimaga
Calculator Community => Casio Calculators => Topic started by: ruler501 on June 15, 2012, 12:30:59 pm
-
I have been working on porting nSDL to the prizm so people can write one program to run on both prizm and both nspires. It now even compiles for on calc :D so it should be ready for anyone who wants to to test it. Until it gets to version 1 and I get most bugs out I will not be distributing binaries so you will have to build it. To compile it run make -f Makefile.prizm and it should compile. to install it assumes you built it in the /projects directory of the prizm sdk then run make -f Makefile.prizm install to install it to your prizm sdk
I need people to help me find any errors I might have made and to test the library. If someone could please help me the code is at https://github.com/ruler501/pSDL It now compiles fine and will run if you use a 8 bit surface. malloc seems to fail if it tries to use a 16bpp surface the size of the screen. If someone could please find a way to get malloc working with large values that could allow much more usability
I could not have done this without hoffa's wonderful nSDL. I have copied most of his code and only changed the parts that are platform specific(mainly).
DEMO:
This is a demo of a program called explosion I cannot currently remember where I got it from. Other than removing functions the prizm doesnt support very little work was needed to port it
Attatched is the binaries for version 1.0.0 I will be updating soon since the current version does not support anywhere near the whole keyboard like it should.
pSDL has also moved so that it is now called pSDL on my github instead of still being called nSDL
EDIT:Touched up the entire post to be more concise and orderly
-
I was about to get a similar project started (I was looking at the SDL sources last week to check the feasibility of the thing), I'll be happy to help you :)
Of course, it'll be easy to have programs that compiles on both Ndless and the Prizm and to have nSDL and pSDL in the same branch, as plateform-specific code are separated in the SDL library (you can see a src/tinspire and a src/prizm directory).
-
Nice!
You can try removing a few of the HAVE_* defines in SDL_config_prizm.h, as SDL does implement a few of the functions. Also doesn't the Prizm have a 320x240 usable screen (EDIT: apparently it doesn't indeed)?
-
I fixed the calc compile by adding a HAVE_MALLOC define to the prizm config not sure if this may break something later on but for now it compiles succesfuly with the sdk. I'm going to reupload the correct version to github as a download if someone could try to see if it works on calc. I won't have a calc available for another 30 min or so so I can't test it myself
-
I'll give a try as soon as I'll get home.
-
Thanks for now I'll just run through the tests and see how that works once I get my calc
-
The FULL screen dims (with FS enlabed) is 396*224.
-
The FULL screen dims (with FS enlabed) is 396*224.
It's hard to get that working with the default buffer and screen copy routine though.
-
We can set that later as what happens when SDL_FULLSCREEN is passed as a flag to the video surface. I'd rather not work on that till I get this working
To get this to compile I define HAVE_MALLOC in the build command so that SDL_malloc.c does not compile. When I do this though I get errors later that a number of functions aren't defined. I think I need to have SDL_malloc.c compile but to do so I have to have the stdlib functions in it work. I'll look through it and try to make a list of what needs to be implemented also if someone could look through it and help find areas that can be worked together without the stdlib or with functions already implemented that would be great
EDIT: these are the compile errors from my test program with SDL http://pastebin.com/Z2EeK5KA
-
I had some pretty serious errors in how I built it I have fixed that in the most recent commit but now there are lots of build errors
I'm going to be in the mountains of new mexico on a hike for the next 9 days so if someone else could work on it and maybe get something fixed I would much appreciate it
-
I'm slowly working through the errors but I am finding things that are missing that need to be added to the SDK for it to compile.
The things I've found so far that need implementation are:
stdint.h (Though i think I got this working acceptably you can see my slightly modified version of it in the include folder of the most recent commit)
stdarg.h(for va_list)
and probably more but until I get past one I can't see the next problems
-
Attached is the image of the first SDL program to run succesfully with video on the prizm
EDIT: wow just realized that this is now a quadruple post
You should be able to run any 8bpp program with pSDL on the prizm with little modification
-
Sweet :D
-
IkaTari said in a few days there might be a way to fix the problem with not being able to allocate enough space for 16 bpp surfaces so that may not be such a large problem
-
Glad to see new progress and I'm glad SDL programs will finally arrive on the PRIZM too. :)
-
maybe currently they are very limited though I'm working to try and fix that though there is not much i can do right now
EDIT: forgot i posted this merged later post
First real complicated program on the prizm is a basic fire demo
EDIT: attatched g3a of demo it should work and exit after 2.5 seconds but I'm sorry if it doesnt and please dont hold me responsible for any damage it does to you calc as i have only tested on manager software so far
-
Looks nice. I hope you can fix all the problems there are. :thumbsup:
-
Looks good! What is SDL, exactly? Is it a new language or a library?
-
SDL is indeed, a library (a set of libraries); it's very portable, and thousands of SDL-based games have been made for dozens of platforms :)
-
Though i think I'll have to port SDL_image so we can use smaller images then bmp(though I'm still not sure if bmp loading works currentlly)
EDIT: since file i/o currently doesnt work I'll find a way to implement the header based images everyone else used for SDL
-
I need some help getting basic image loading working. I use the two arrays from sourcecoders conversion to 8 bit to create the surface. the image appears to be blue shifted on everything.
SDL_Color rgb16to24(Uint16 x)
{
SDL_Color newcolor;
newcolor.b= (x & 0x1F) * 8;
newcolor.g = ((x >> 5) & 0x2F)* 4;
newcolor.r = ((x >> 11) & 0x1F)* 8;
return newcolor;
}
SDL_Surface* LoadSCImage(Uint16* pallete, int paletteSize, unsigned char* image, int x, int y)
{
int i, j;
SDL_Color newColors[paletteSize];
for (i = 0; i < paletteSize; i++)
{
newColors[i] = rgb16to24(pallete[i]);
}
SDL_Surface *tempsurf = SDL_CreateRGBSurface( SDL_SWSURFACE, x, y, 8, 0,0,0,0);
for (i = 0; i < y; i++)
{
for (j=0; j < x; j++)
{
*(Uint8 *)(tempsurf->pixels + i*tempsurf->pitch + j) = image[i*x + j];
}
}
SDL_SetColors(tempsurf, newColors, 0, paletteSize);
return tempsurf;
}
-
You could use the simple image format (https://github.com/Hoffa/nSDL/wiki/NTI-specification) I'm using for nSDL. The code is very short (here (https://github.com/Hoffa/nSDL/blob/master/src/video/tinspire/SDL_tinspirenti.c)) and it returns a 16-bit/8-bit surface. It should require no changes to compile, and would assure some sort of compatibility between both platforms.
-
I think I will implement that too.
I'll be putting these in a second library called pSDLlib so that my pSDL port remains SDL and pSDLlib is an addition for easier use
thanks hoffa.
-
Image Loading Cross Post from Cemetech
I couldnt get 8 bit working but heres the function that correctly loads 16 bit SDL_Surface* LoadSCImage(Uint16* image, int x, int y)
{
SDL_Surface *rimage, *tempsurf = SDL_CreateRGBSurfaceFrom(image, x, y, 16, 2*x, PZM_RMASK16,PZM_GMASK16,PZM_BMASK16,0);
rimage = SDL_DisplayFormat(tempsurf);
SDL_FreeSurface(tempsurf);
return rimage;
}
I'll compile this and a few things from hoffa's nSDL to a seperate library when i came back to work on this in August
-
Good luck! ALso i watched the video and it looks pretty nice :). I hope this allows more games to be easily produced for this calc in the near future. :)
-
I'm back now and now I need to decide what I need to do with this project. I think that one of the main things that will need to be done is get the events to recognize all keys. If anyone knows a way to do this please tell me. I also plan on making some demo's and trying to find more efficient ways to implement some of the internal functions.
What I need help with:
Testing what keys are down for the entire prizm keyboard
Getting file i/o for bmp loading
Getting other SDL libraries working(SDL_gfx most importantly)
If I could get these things working I think it would greatly improve this library
-
Welcome back. I unfortunately cannot help but hopefully someone can answer in the PRIZM section. You might need to create a separate topic, though, so people notice your question.
-
*Necropost?*
I'm guessing that progress hasn't been very good lately?
-
I haven't done anything with it since I got back. I haven't really done much coding overall. If there are any problems or requests I'll probably look into it but I make no promises for now
-
Hopefully you don't stop coding completely D:
-
I haven't stopped I actually wrote a small program in python just the other day. I just haven't been doing much calc stuff and I'm focusing most of my time on learning more in math and science.
-
Aah ok good to hear. Hopefully you have more time to do some calc stuff soon :)