Omnimaga
Calculator Community => Other Calc-Related Projects and Ideas => TI-Nspire => Topic started by: Matrefeytontias on June 12, 2013, 02:58:18 pm
-
Hallaw guys,
This is something I wanted to do since ... a year or two :P but I never got it to understand and apply correctly the technique of raycasting.
BUT ! Now it's done :D
So I wrote this library which I named nRayC, because it's an Nspire lib about RAYcasting to be used in C ;D
Although this library is mainly focused on raycasting, it's not its only use : I also included a bunch of functions, like pixel, line and even triangle (why not) drawing, tile detection, bitmaps loading and stuffs.
Currently, the library features raycasting rendered by a unique function :
void nRC_rayCasting(int *map, Vector player, ScreenPoint mapDimensions, Vector dir, Vector planeVec, uint16_t *textures, char *buffer)
It also provides two structures as you can see, ScreenPoint and Vector. I don't release anything for now because I don't think it's ready to be released, but I attach a screenshot of what it can do :)
I'm working actively on it, so expect progress every 2 days ;D
Share comments :)
-
That looks very nice!
Does it run fast even with textures?
-
Indeed that looks awesome. :thumbsup:
And I guess it remains fast with textures, see nDoom which is pretty fast. :)
-
Thanks :)
Yeah it's really fast - even too much, I had to set the movement speed to 0.5 and the rotation speed to 6° to be able to move and see what's going on at the same time :P
-
Nice, I'm looking forward to the release :)
-
Awesome! Is this based on Permadi or the lodev info source?
Either way it looks really good, and to hear it runs fast is great :).
-
Looks interesting, indeed :)
-
Update :P
I finished writing a working R5G6B5(r,g,b) macro, which automatically converts either to R5G6B5 for CX calcs, or a corresponding greyscale for non-CX calcs :) (among other things :P)
I felt like I could post a small demo ;) you need both test.tns and textures.bmp.tns. Since I didn't take care of paths, textures.bmp.tns needs to be in "/documents/ndless/" for the program to work.
I could test it with my Nspire CAS, but I couldn't test with a CX, so if CX users could test it and tell me how it runs, it'd be cool :)
Also @tr1p1ea : it's based on Lode's technique.
-
Wow, that's looking cool! And I hope that it has a good speed with textures so that we can get over 9000 fps :P
-
tested and approved ;)
-
Awesome. Though the texture scaling code in the lode example code can really be optimised a lot if you wanted to dive into it deeper.
-
When I try to run test, nothing happens at all? After running it I can still select through the documents menu like if I didn't even press Enter. I sent both files fine.
Nspire CX non CAS btw
-
Did you put textures.bmp.tns in “/documents/ndless/“ ?
-
Bump,
Ready to play the first mini-game ever programmed with nRayC ? :P
I programmed a small maze as a proof of concept ; it runs fast enough, has 5 64*64 textures including one edited each frame (the exit is a block of moving plasmaaaaa :crazy:) and 4 loaded from an external bitmap, and collision detection to detect the exit :)
To play, same than before : put test.tns wherever you want and textures.bmp.tns in "/documents/ndless/".
And the source is ... 105 lines, including a 24-lines map declaration :thumbsup:
I also release both the source of the example and the engine :D
For now, the engine is nRayC.c and nRayC.h, but later I'll write a doc and compile it in a static lib. You can still use test.c and the functions' prototypes as a small doc ;)
Also beware : the program is much, MUCH slower on an emulator than on-calc. At least on my PC :P
-
Cool :)
But why don't you use a relative path so we could put the textures.bmp.tns in the same directory as the game?
Also beware : the program is much, MUCH slower on an emulator than on-calc. At least on my PC :P
That's strange, all programs I've seen so far were a bit faster on an emulator than in reality. Also, it's quite fast in nspire_emu on my PC. Faster would be too fast :P
-
Cool :)
But why don't you use a relative path so we could put the textures.bmp.tns in the same directory as the game?
Because they are not automatically handled by the Nspire, and because I was too lazy to write a function to do it at the time I wrote the demo :P but it's something planned for the engine.
Also beware : the program is much, MUCH slower on an emulator than on-calc. At least on my PC :P
That's strange, all programs I've seen so far were a bit faster on an emulator than in reality. Also, it's quite fast in nspire_emu on my PC. Faster would be too fast :P
As I said, maybe it's only my PC :P
-
Not sure what you mean ???
fopen("textures.bmp.tns", "r")The above code would open a file in the same directory as the executable? I'm almost sure I've used such code and it worked.
Edit: Sorry, you're right, doesn't work. I was sure I'd used it before, but apparently it really assumes "/documents/" as the folder if one doesn't use an explicit folder.
-
Did you put textures.bmp.tns in “/documents/ndless/“ ?
Oh I forgot to do that, I actually put it in the same folder as the test program lol.
By the way, will this program support 4, 8 and 24 bits textures? It would be nice for people who don't want to install GIMP, because no other image editor that is freeware can save in 16-bit format.
-
Yeah of course I planned that. But like many other things, it'll come later.
-
Could I please port this to Prizm?
This is great. Keep up the good work! :D
-
Nice Matrefeytontias :)
I suppose that cross-platform compatibility would require SDL, if it's now available on PRIZM.
-
@Spenceboy98 no problem, but you'd prefer to wait a little until I put in the lib some things to make its use easier (I have some defines in mind).
@ExtendeD Why that ? I didn't use any other library than the one I wrote ... <and fdlibm>
-
Cool :)
But why don't you use a relative path so we could put the textures.bmp.tns in the same directory as the game?
Because they are not automatically handled by the Nspire, and because I was too lazy to write a function to do it at the time I wrote the demo :P but it's something planned for the engine.
Use argv[0]. :)
-
Here's the code used in nSDL to use relative paths:
int nSDL_EnableRelativePaths(char **argv) {
char buf[256], *p;
strcpy(buf, argv[0]);
p = strrchr(buf, '/');
if (!p)
return -1;
*p = '\0';
return NU_Set_Current_Dir(buf) ? -1 : 0;
}
-
Thanks hoffa, I'll use this one :)
-
Thanks hoffa, I've added it to Ndless/libndls.
-
@Spenceboy98 no problem, but you'd prefer to wait a little until I put in the lib some things to make its use easier (I have some defines in mind).
I actually got the most recent version to work(though there are some weird display errors :/ ). :P But I'll wait for updates.
-
If you ever decided to use nSDL for the Nspire version, for a PRIZM port you could always ask Ruler501 if he ever released pSDL, since he was working on that PRIZM port of nSDL a few years ago.
-
My goal is to write a stand-alone lib, so there's no chance that I'd use any other lib.
-
Bump,
nRC_loadBMP now automatically detects and handles :- 1-bit monochrome bitmaps (B/W)
- 4-bits grayscales bitmaps (16 colours)
- 16-bits R5G6B5 bitmaps (65,536 colours)
- 24-bits R8G8B8 bitmaps (16,777,216 colours, but they are scaled down to the Nspire screen, so either 16 or 65,536 colours)
They're the most common types of bitmaps :) I planned the support for paletted bitmaps for later, since it's pretty complicated.
Also, I added some constants to make porting the engine easier, so this should make your life easier Spenceboy98 :)
Also, the new build of the demo now uses relative paths, so you just have to put textures.bmp.tns in the same directory :thumbsup:
I also formatted the whole directory in a logical way x) documentation will be included in the next release (I hope :P)
EDIT : of course, if you have any wish for this engine, please share your ideas, I'll be happy to add them to my TODO list :)
-
Good to hear about extra bitmap format support! Now we can use custom graphics to try the demo :D (For example if someone wants to see how the engine looks like with Unreal Tournament textures). Keep up the good work! :)
-
If you want to do that, you'll have to load a bitmap which is made out of 64*64 tiles and which has the exact same size than the currently used bitmap ! Also, the 64*64 white square is the area used to draw the plasma texture.
-
I'm fine with that. :P Now I just need to rip Illusiat 6 graphics. :P
-
Be sure to post a screenshot, or even better the textures file :D
-
I was wondering if for some textures, you could actually generate some programmatically (especially for geometric ones), maybe it would take less size ?
-
Be sure to post a screenshot, or even better the textures file :D
I can't, because I never figured out how to install Ndless 3.1 on the emulator. It would have to be a camera pic or video.
-
With Ndless 3.1 it's actually not really different than installing it on real HW. Create the folder ndless/, transfer ndless_resources to it, then ndless_installer as an OS update (there's an nspire_emu command for this in the link menu). it's a matter of seconds :)
-
Ah ok I didn't realize we could send OS updates to the emu. I thought I had to do some strange manipulation via command line and maybe even with Boot1/2 files or something. Thanks :)
-
Bump,
nRC_loadBMP now automatically detects and handles :- 1-bit monochrome bitmaps (B/W)
- 4-bits grayscales bitmaps (16 colours)
- 16-bits R5G6B5 bitmaps (65,536 colours)
- 24-bits R8G8B8 bitmaps (16,777,216 colours, but they are scaled down to the Nspire screen, so either 16 or 65,536 colours)
They're the most common types of bitmaps :) I planned the support for paletted bitmaps for later, since it's pretty complicated.
Also, I added some constants to make porting the engine easier, so this should make your life easier Spenceboy98 :)
Also, the new build of the demo now uses relative paths, so you just have to put textures.bmp.tns in the same directory ;D(http://www.omnimaga.org/Themes/default/images/gpbp_arrow_up.gif)
I also formatted the whole directory in a logical way x) documentation will be included in the next release (I hope :P)
EDIT : of course, if you have any wish for this engine, please share your ideas, I'll be happy to add them to my TODO list :)
Yay! I will try to start porting when I can(I also have to work on my cemetech contest entry). Could I use your loading BMP routine for my Prizm Paint?
-
Yeah, please do, but please give me credits for it :) also good luck for your port !
I was wondering if for some textures, you could actually generate some programmatically (especially for geometric ones), maybe it would take less size ?
Yeah of course, but then you won't be able to add a generated texture to an array of already loaded ones unless you planned a blank 64*64 spot in the texture file to store it (that's what I did to store my plasma in the demo).
But of course you can still produce an array only made out of generated textures. But once again you won't be able to load textures from files and put them in the same array.
-
With custom texture support, it was only a matter of time before this happen:
-
You see ? It works well :P
/me lost (thanks DJ)
-
Okay. It looks messed up, but here's Prizm screenshots:
When you enter the game:
(http://i41.tinypic.com/2mfxikj.jpg)
Later in the game:
(http://i43.tinypic.com/35mgnit.jpg)
In the same spot:
(http://i40.tinypic.com/ofcpj.jpg)
At the end(the plasma doesn't work right :/ ):
(http://picasion.com/pic70/4e487af0c6f67e7769741814dd0edadd.gif)
I think the reason it isn't rendering right is because of my sqrt routine. The Prizm SDK doesn't have one, so I had to find one online. Here it is:
double sqrt1(double x){
if(x<0) return 1;
double a = 1;
double b = x;
while (abs(a-b)>1){
a = (a+b)/2;
b = x/a;
}
return a;
}
Maybe one of you knows a better way for sqrt(sorry to ask in this topic, but I don't have another)?
-
Okay. It looks messed up, but here's Prizm screenshots:
When you enter the game:
You don't lose? O.O
Looks kinda cool so far despite not rendering well. How high is the frame rate on a real calculator?
-
Take a look here: http://www.codeproject.com/Articles/570700/SquareplusRootplusalgorithmplusforplusC
It's more complex, but I think it will be faster (better algorithm).
-
By the way, would this engine work with a gradient as the floor and a scrolling background for the sky?
-
Of course, I'm adding these functions to my TODO list :
- nRC_floorCasting
- nRC_ceilCasting
- nRC_scrollingSky
-
Take a look here: http://www.codeproject.com/Articles/570700/SquareplusRootplusalgorithmplusforplusC
It's more complex, but I think it will be faster (better algorithm).
Now it freezes(stuck in a while loop I think) inside the plasmaBuffer loop. :/
Can't wait for the floorcasting and shtuffs. :D
-
Oh floorcasting would be nice too. Would it be very slow if combined with raycasting, though?
-
Well, we'll see, but since the raycasting alone is heavily unoptimized, although very fast, there is still some speed to gain.
-
This raycaster looks pretty awesome. Hopefully someone makes a cool game with it. :D
-
I planned to make one as soon as the engine is done :)
-
Oh cool ! :D What type of game will it be ? Cause all I can see is an FPS ATM.
-
It's a surprise, since it's a game that never met calculators before ;)
-
I'm pretty excited about it then. :) Good luck !
-
Yeah but I won't start it before a while, since I need the engine to be complete enough first :P
-
I can't wait for the game but good luck with the engine first. :P
-
I was wondering how you plan on adding doors?
-
Simple : it's not planned yet :P
-
What about variable wall and camera height? (Like in calc84maniac's 84+ raycaster)
-
Lol, there are a few ways that you can achieve doors, however it will require modification of the wall detection loop since you need to allow for the fact that doors are 'half-way' in a wall (or offset by half a wall etc) and sometimes reinstate a ray if needed (like when its opening).
That said, its not on the plan yet, but something to think about.
-
DJ_O variable camera height is planned, IDK about walls yet.
tr1p1ea that'll come way later anyway :P
-
On a side note here's the raycaster I am talking about:
(http://img13.imageshack.us/img13/5633/variable.gif)
Unfortunately OTBP website is gone and I couldn't find any topic about it here, so I had an hard time finding the image.
-
Oh but this is not jumping/crouching, this is looking up or down O.O I can't do that with my current engine ...
But seeing the screenshot, I can barely see how to do variable-height walls, so it should be OK.
-
Actually I think looking up and down simply involves moving the screen content up and down in the screen, with no extra 3D calculations. It's kinda like in Duke Nukem 3D (the original version, not remakes nor the hi-res pack), but of course like in that game when you look too high in the sky, the buildings look distorted.
(http://www.3drealms.com/duke3d/images/walkthrough/e2/e2m5_22_small.jpg)
Also moving the camera height up and down would be the problem.
-
Actually I don't really know, I'll search some info about that.