Omnimaga
Calculator Community => Other Calc-Related Projects and Ideas => TI-Nspire => Topic started by: bwang on March 23, 2010, 01:23:20 am
-
I finally got around to writing some code for my Nspire raycaster project. Right now it is shamefully featureless, as it basically draws untextured walls from a scene defined by a hard-coded array in the source:
(http://img16.imageshack.us/img16/4990/screenshotnspireemu.png) (http://img16.imageshack.us/i/screenshotnspireemu.png/)
The big problem I'm having right now is getting the animation not to flicker (the above screenshot was not animated). Does anyone here (maybe calc84maniac?) know how to do flickerless animation on the Nspire?
Once I get the animation working, I'll add other things, like texture mapping and sprites. Also, does anyine know how to pause execution for a specified amount of time (so I can limit the frame rate)? Right now, from my preliminary flickery code, it seems like I have plenty of speed to work with.
-
wow awesome, I hope to see more work on this :)
I wonder if you could eventually combine both raycasting and Mode 7? Calc84 did Mode 7 and raycasting, altough on z80, but he could maybe help for the Mode 7
-
Nice, glad to see you got this working. Did you end up using the small step or the vertical/horizontile method? Judging from the side shading on the walls I'm guessig it's the latter? Looks good :)
-
The horizontal/vertical method.
-
Seems you might have a case value for the column directly in front of the camera :P maybe offset all of the columns by .5 degrees?
-
I wonder... in the future, will you implement variable wall height? Calc84maniac had a raycaster using these in the works for a while for the 83+:
(Must view in Firefox or Opera, since other browsers won't support 30 fps gifs)
(http://img16.imageshack.us/img16/9180/raycaster.gif)
(http://img13.imageshack.us/img13/5633/variable.gif)
-
Great!
I've got one little additional remark: most of the screen is left unused. I've never written raycasting/raytracing code, but is there a reason?
As for flickering, calc84 should know, he wrote the GBC emulator and such.
-
The raycasters on the 84+ with textures (Wolfenstein83 and Gemini) don't use a large part of the screen either.
This because making it wider (so having to check more lines) uses a lot of recources.
Even at the 68k's a big part of the screen is not used for the raycasting.
The raycaster Cal84 made runs full screen but note not a lot of textures are added, no enemies so no AI having to run , no objects.. (:
I love those damn screenies
-
Keep in mind, though, that the Nspire is 90 MHz (or more?) while the 83+ is 6 MHz.
-
I'm seeing some Halo in the future. :D :D
-
I think I can implement variable wall heights. The emptyness of the screen is because my walls are not very high, which is easily fixed. Right now, my biggest priority is figuring out how to get smooth motion.
From what I have right now, I think I have plenty of speed left, especially since I haven't started optimizing yet.
-
What will be the maximum amount of shades of gray supported? (knowing the Nspire can do 16)
-
Once I get texture mapping done, it will support 16 shades. Right now, there are only two shades.
A question: in src/arm/headers/common.h in the Ndless package, there are several keycodes. Does anyone know where I can find more of these codes? Also, are the direction keys also considered keys, or is it some sort of analog device with infinitely many directions?
-
aaah ok, I was unsure. 4 levels of gray would be ok, though. Even monochrome, altough it wouldn't be pushing the Nspire to its limits as much XD. But we have to start small when coding anyway, IMHO. It's good to be ambitious, sometimes, but we have to make sure to not be way too ambitious either. ^^
Some people who are totally new at something will sometimes go with the largest possible RPG project, then realize it was too much for them x.x. I usually start with something small, see if I can do it, then expand.
-
aaah ok, I was unsure. 4 levels of gray would be ok, though. Even monochrome, altough it wouldn't be pushing the Nspire to its limits as much XD. But we have to start small when coding anyway, IMHO. It's good to be ambitious, sometimes, but we have to make sure to not be way too ambitious either. ^^
Some people who are totally new at something will sometimes go with the largest possible RPG project, then realize it was too much for them x.x. I usually start with something small, see if I can do it, then expand.
16-level gray is pretty easy to do, considering the Nspire has hardware grayscale support.
I don't feel this project is terribly ambitious yet. Notice I have absolutely nothing planned for gameplay--right now, I'm just experimenting with raycasting.
-
aaaah ok I see ^^, but on my side, stuff that technical is very hard to understand x.x. It's not necessarly just cuz of the low level programming, but more understanding 3D, because someone did a TI-BASIC raycaster before and I still couldn't understand, even if it was written in TI-BASIC, which I programmed for 9 years. Axcho from UTI is the person who did the program.
-
Never mind the key code question; I found the key codes here: http://hackspire.unsads.com/wiki/index.php/Memory-mapped_I/O_ports#900E0000_-_Keypad
-
Hmm, what is this "flickering" you speak of...
-
I believe he wants to know how to draw to the buffer without updating the screen.
-
I believe he wants to know how to draw to the buffer without updating the screen.
Draw to another buffer and copy it over, I would think.
-
What is the best way to create a second buffer? I tried making a 320x240 array, but the program just crashed.
-
I don't have double buffering working yet, but I do have texture mapping:
(http://img716.imageshack.us/img716/4990/screenshotnspireemu.png) (http://img716.imageshack.us/i/screenshotnspireemu.png/)
The textures are only 8x8 though, since I had to hand-code them.
-
Darn awesome! How many FPS do you get approximately on calc? (remember you'll have to slow down framerate a bit for on-calc usage since the Nspire LCD is so blurry) Also are these textures 8x8?
-
Yay! Higher walls! That looks very cool! :D
-
Yup, the textures are 8x8.
I can't really tell how many FPS I'm getting. I think any numbers I get right now would be meaningless, since I have a feeling much of the time is spent refreshing the screen every time I draw a pixel.
-
A 320x240 array is wayyy too big. (Also, it doesn't help me if I don't know the size of the elements)
And what do you mean "refreshing the screen every time I draw a pixel"
-
A 320x240 array
meaning >9000 :O
Sorry couldn't resist :P
-
I'm using the setPixel() function from the Ndless demo to draw to the screen, which I presume has to refresh the LCD every time it is called.
The array elements are ints.
-
320x240? Thats MASSIVE! Are there going to be any speed issues with checking against an array of that size?
Also you might be able to come up with a nifty verticle scaled texture-slice routine to speed things up mebbe? (or cheat and store pre-scaled textures to match each change in height position?)
Either way it looks awesome, i want to buy an Nspire just to test :D.
-
I'm using the setPixel() function from the Ndless demo to draw to the screen, which I presume has to refresh the LCD every time it is called.
The array elements are ints.
I assume the setPixel() function writes to the LCD memory, and I know the LCD updates itself automatically when it refreshes. And each pixel is 4 bits, so using ints for the array makes it 8 times as big as it needs to be.
-
Well you could pack multiple columns into 1 write?
-
Would the array work if I made it 8 times smaller? Do you guys think its crashing because of lack of memory?
-
Would the array work if I made it 8 times smaller? Do you guys think its crashing because of lack of memory?
I am not sure exactly what method you are using. But trying to copy an extra-large array to the LCD ram would probably overflow to other sensitive memory.
-
My guess is that each memory sector is 65536 bytes, right?
(such array would most likely be 76800 bytes large, unless I am wrong, right?)
-
My guess is that each memory sector is 65536 bytes, right?
(such array would most likely be 76800 bytes large, unless I am wrong, right?)
I have no idea how the flash memory on the Nspire works, actually. Though, we are talking about RAM here, which isn't really in "sectors". And the array would actually be 38400 bytes, since there are 2 pixels per byte.
-
I'm not even trying to copy the array right now. Just trying to put values in the array crashes the calculator.
-
Yay! I implemented double buffering, and its much less flickery now. For some strange reason , though, it flickers and becomes choppy when you get near a wall.
Screenshot:
(http://img87.imageshack.us/img87/6189/imgv.gif) (http://img87.imageshack.us/i/imgv.gif/)
It runs a lot smoother on-calc than the screenshot makes it seem (why won't CalcCapture give me a higher framerate?)
I've attached a demo.
-
WOW! So much greatness!!!
Darn keep up the good work on this! Btw did you try with higher resolution textures too? I wonder if it slows it down a lot?
-
I think texture resolution shouldn't affect speed, since the loop that does the texture mapping depends only on the height of the column I'm drawing.
Speaking of texture mapping and speed, I think I figured out the cause of the slowdown when you get near a wall: the columns become longer, so the engine needs to do more texture calculations. I guess my texture mapper really needs optimization :(
-
Ouch I wish you luck x.x. Glad texture res shouldn't affect speed, though
/me suggests Bwang the following TI-Nspire project:
(http://xlib.mtv-music-generator.com/nspire3D.png)
just kidding :P
-
/me bows to the awesomeness of bwang's TI-Nspire hacker skills
This could be passed of as a flash game or something...
-
Bwang, that's really awesome! Keep up the great work! ;D
-
That looks really good. TI calculator programming has entered a new era 8)
-
Awesome screenie. Textures are next, I guess.
A fog effect would be really nice to see too. :P
-
I already have texture mapping--those checkered squares are an 8x8 texture map.
-
I really want to buy an NSpire now
-
Yepeee! Are you planning some sort of beta in the near future so that we can test it on real hardware?
-
I did attach a small demo in the post with the screenshot in it. It runs a bit slow, though, since I haven't fixed my texture mapping code yet.
-
@bwang, you can increase the speed of CalcCapture by changing the capture interval under File Properties.
-
Hmmm... Seems I skipped the part where it said "demo attached". I suppose I was too distracted by the awesomeness of the screeny... :P
-
Are you planning to implement floor and ceiling textures? What you've got is amazing already, don't mistake me there. Good work ;D
It looks as if you're using the entire screen, am I right? If so that's also quite amazing, most raycasters on calculators can only be done with a section of the screen, I guess that fancy newfangled processor really is fast enough to handle things like that.
Stuff like this is probably going to be the reason I end up buying the nSpire. :)
Did you say that your textures are 8x8?
Are you planning on using that resolution for the final product?
The only thing i would point out is that if you keep that resolution, it will make it rather difficult to make games using this engine that have a lot of visual details.
-
If you want to buy an Nspire, buy the non-CAS blue one.
-
Why?
-
The black ones don't support Ndless yet and the CASes don't have an 84+ keypad.
The final textures definitely will not be 8x8. I am using the entire screen. Whether I use floor textures will depend on how much speed I have left.
-
Keep in mind that Ndless is coming for OS 2.0, though, so people with newer Nspires that cannot be downgraded below 2.0 will be fine. Just letting you know. However, I don't know the last news about this. I know exploits were found and all, and proof-of-concept screenshots of Ndless running on OS 2.0 were shown on both active french TI forums.
Don't get a CAS, though. First, a TI-89 emu will eventually come out for the Nspire, giving you most CAS functions if you absolutely need them in math, secondly, the CAS doesn't support the 84+ keypad (unless this changed with the new CAS?) and it's much more expensive than the regular Nspire.
-
New screenshot with higher resolution (32x32) textures:
(http://img532.imageshack.us/img532/4990/screenshotnspireemu.png) (http://img532.imageshack.us/i/screenshotnspireemu.png/)
Does anyone have advice to give on writing a faster texture mapper? I get twice the framerate I get now if I take out texture mapping, so clearly it is a major source of slowdown.
-
How many divisions are you doing per column? Would it help to change them to bit shifts, since your dividing by 32?
-
They're all bit shifts now.
-
looks nice! I hope you find a solution for the speed. Does it run really really slow? Or does it run more like Gemini for the 83+?
-
The motion is smooth as long as you don't get too close to the walls. If you do, the engine needs to calculate textures for more pixels and it becomes choppy.
-
puǝ
puǝ
(ɐ)sןǝxıdʍɐɹp
(ʇuǝɯbǝs ɟo ʇɥbıǝɥ)ɹoɟ
ɐ>-ɹoןoɔɔןɐɔ
(13 oʇ 0)ɹoɟ
:buıʞuıɥʇ ɯ,ı ʇɐɥʍ ɹoɟ ǝpoɔopns ǝɯos ǝʞıן
o˙o sןǝxıd ǝɹoɯ oʇ buıʍɐɹp ǝɹɐ noʎ ǝsnɐɔǝq ʎןǝɹǝɯ ssoן pǝǝds ǝɥʇ sı ɹo ¿ǝɹnʇxǝʇ ǝɥʇ ɟo uoıʇɔǝs ɥɔɐǝ ɹoɟ ǝuo ¿sǝɯıʇ 23 ʎןuo uɯnןoɔ ɥɔɐǝ ɹoɟ ǝɹnʇxǝʇ ǝɥʇ pǝʇɐןnɔןɐɔ noʎ ɟı dןǝɥ ʇı pןnoʍ
-
The speed loss is because of extra calculations needed when the column is taller. Builderboy: how would you find the height of each segment? That seems to require quite a bit of math.
Bricks!
(http://img231.imageshack.us/img231/4990/screenshotnspireemu.png) (http://img231.imageshack.us/i/screenshotnspireemu.png/)
I'm contemplating rewriting everything to use only integer arithmetic. Do you guys think the resulting speed gain will be worth the trouble?
I attached a new demo. Why doesn't the forum support .tns attachments?
-
Mmm could you multiply the height of the section by .03125? Would that be faster than dividing by 32? This way there wouldnt be any extra calculations for taller columns, only the overhead of drawing the pixels.
-
I will add tns attachment support asap, sorry I kinda forgot since it was not a commonly-used file on the forums until Ndless came out :P
Also looks nice so far ^^.
-
Wow the new 32x32 bit textures look great. I would highly suggest studying the code from the FAT engine, it was able to render 64x64 bit textures on a 10mhz calc (although it was only rendering to a 96x96 pixel screen), you've got a lot more processor speed to work with, despite the fact that your engine uses the whole screen, I think you could use some of the optimization concepts from that engine in your code.
Also do you have a maximum distance for rendering coded in yet? if not you could glean a few FPS's of speed from not even bothering with tiles that are outside of that distance. You probably have, but that's just a thought. At a certain distance and beyond, the walls would all render as a single pixel in each column, so there's no real need to calculate anything at that distance and beyond. It would make more sense to just render a pixel.
Also after a certain distance, you could just abandon textures, and just render the wall as a solid color, like black would be good, because it would appear that you just couldn't see that texture, and it would probably speed things up a bit.
Just a couple of thoughts. I tried writing a raycasting engine for the HP50g once, and only managed to make a really fish-eyed representation of the walls, and only in one color, so I think your expertise in these matters severely outweighs mine ;D
Good work! Keep it up! It won't be long and I might be working on a Wolfenstein port for the nSpire.
-
is it very hard to detect if some stuff is located farther?
-
Good idea, I'll add the maximum distance code.
calc84: how do you change the CPU clock speed in C?
-
Good idea, I'll add the maximum distance code.
calc84: how do you change the CPU clock speed in C?
To set 150MHz, do this:
*(unsigned*)0x900B0000 = 0x00000002;
*(unsigned*)0x900B000C = 4;
To set 90MHz, do this:
*(unsigned*)0x900B0000 = 0x00141002;
*(unsigned*)0x900B000C = 4;
-
Just out of curiosity, what do the bits in 0x00000002 and 0x00141002 do?
-
Very very impressive project thus far.
Question I have is will it support being able to look up and down? A user on my forums (SuperKoolKid) was going to make an engine for the 68k that allowed that, but he has seemingly stopped the project due to not having the time or motivation to work on it.
If you did, we could have some really epic games made. XD
-
(on a offtopic note I wonder where SuperKoolkid went..., his engine would have been amazing. Only Calc84maniac did that besides SKK and he didn't release a demo yet, not to mention it's dormant
-
Question I have is will it support being able to look up and down?
That depends on how computationally intensive looking up and down is, how much speed I have left after adding sprites, and how much I can optimize the code.
calc84: The clock speed changing code you posted doesn't seem to do anything. Is there a special way I have to use it, or can I just stick it anywhere in my code?
-
Is it a calc-only feature or will it work on emulator too?
-
I don't think it works on the emulator. Also, check http://hackspire.unsads.com/wiki/index.php/Memory-mapped_I/O_ports#900B0000_-_Power_management (http://hackspire.unsads.com/wiki/index.php/Memory-mapped_I/O_ports#900B0000_-_Power_management) for information on what the bits do.
-
Very very impressive project thus far.
Question I have is will it support being able to look up and down? A user on my forums (SuperKoolKid) was going to make an engine for the 68k that allowed that, but he has seemingly stopped the project due to not having the time or motivation to work on it.
If you did, we could have some really epic games made. XD
I fairly sure no matter what epic games are in the near future ;D
-
Hmm...the clock speed stuff doesn't seem to work on my calculator, either. Maybe it has something to do with hardware changes in newer calcs?
-
You might want to post the source code in case there might be something wrong in it so people can help figuring out. But again, it could be due to hardware change (which I hope not)
-
Source Code:
#include <os.h>
#include "utils.h"
#include "rayheader.h"
#define mapWidth 24
#define mapHeight 24
#define texW 32
#define texH 32
#define cos1 0.9950
#define sin1 0.09983
#define stpsize 0.2
asm(".string \"PRG\"\n");
int main(void)
{
*(unsigned*) 0x900B0000 = 0x00000002;
*(unsigned*) 0x900B000C = 4;
int map[mapWidth][mapHeight]=
{
{1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1},
{1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1},
{1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1},
{1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1},
{1,0,0,0,0,0,1,1,1,1,1,0,0,0,0,1,0,1,0,1,0,0,0,1},
{1,0,0,0,0,0,1,0,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,1},
{1,0,0,0,0,0,1,0,0,0,1,0,0,0,0,1,0,0,0,1,0,0,0,1},
{1,0,0,0,0,0,1,0,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,1},
{1,0,0,0,0,0,1,1,0,1,1,0,0,0,0,1,0,1,0,1,0,0,0,1},
{1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1},
{1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1},
{1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1},
{1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1},
{1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1},
{1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1},
{1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1},
{1,1,1,1,1,1,1,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1},
{1,1,0,1,0,0,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1},
{1,1,0,0,0,0,1,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1},
{1,1,0,1,0,0,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1},
{1,1,0,1,1,1,1,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1},
{1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1},
{1,1,1,1,1,1,1,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1},
{1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1}
};
char* scrbuf = (char*) malloc(SCREEN_BYTES_SIZE);
int tex[texW][texH];
int u, v;
for (u = 0; u < texW; u++) {
for (v = 0; v < texH; v++) {
tex[u][v] = 6;
}
}
for (u = 0; u < texW; u++) {
for (v = 0; v < texH; v++) {
if (u % 4 == 3 || (v % 8 == 2 && ((u / 4) % 2) == 0) ||
(v % 8 == 6 && ((u / 4) % 2) == 1)) {
tex[u][v] = 15;
}
}
}
float px = 12, py = 12;
float dx = -1, dy = 0;
float plx = 0, ply = 0.66;
int w = 320, h = 240;
int x, y;
int redraw;
while (!isKeyPressed(KEY_NSPIRE_ESC)) {
redraw = 0;
if (isKeyPressed(KEY_NSPIRE_LEFT)) {
float olddx = dx;
dx = dx * cos1 - dy * sin1;
dy = olddx * sin1 + dy * cos1;
float oldplx = plx;
plx = plx * cos1 - ply * sin1;
ply = oldplx * sin1 + ply * cos1;
redraw = 1;
}
if (isKeyPressed(KEY_NSPIRE_RIGHT)) {
float olddx = dx;
dx = dx * cos1 + dy * sin1;
dy = -olddx * sin1 + dy * cos1;
float oldplx = plx;
plx = plx * cos1 + ply * sin1;
ply = -oldplx * sin1 + ply * cos1;
redraw = 1;
}
if (isKeyPressed(KEY_NSPIRE_UP)) {
if (map[(int) (px + stpsize * dx)][(int) (py)] == 0) px += stpsize * dx;
if (map[(int) (px)][(int) (py + stpsize * dy)] == 0) py += stpsize * dy;
if (px < 0) px = 0;
if (px > 24) px = 24;
if (py < 0) py = 0;
if (py > 24) py = 24;
redraw = true;
}
if (isKeyPressed(KEY_NSPIRE_DOWN)) {
if (map[(int) (px - stpsize * dx)][(int) (py)] == 0) px -= stpsize * dx;
if (map[(int) (px)][(int) (py - stpsize * dy)] == 0) py -= stpsize * dy;
if (px < 0) px = 0;
if (px > 24) px = 24;
if (py < 0) py = 0;
if (py > 24) py = 24;
redraw = true;
}
if (redraw) {
memset(scrbuf, 0x00, SCREEN_BYTES_SIZE);
for(x = 0; x < w; x++) {
float raypx = px;
float raypy = py;
int mapX = (int) raypx;
int mapY = (int) raypy;
float cameraX = 2 * x / (float) (w) - 1;
float raydx = dx + plx * cameraX;
float raydy = dy + ply * cameraX;
float sideDistX;
float sideDistY;
float raydx2 = raydx * raydx, raydy2 = raydy * raydy;
float deltaDistX = sqrt(1 + raydy2 / raydx2);
float deltaDistY = sqrt(1 + raydx2 / raydy2);
float perpWallDist;
int stepX;
int stepY;
int hit = 0;
int side;
if (raydx < 0) {
stepX = -1;
sideDistX = (raypx - mapX) * deltaDistX;
} else {
stepX = 1;
sideDistX = (mapX + 1.0 - raypx) * deltaDistX;
}
if (raydy < 0) {
stepY = -1;
sideDistY = (raypy - mapY) * deltaDistY;
} else {
stepY = 1;
sideDistY = (mapY + 1.0 - raypy) * deltaDistY;
}
while (!hit) {
if (sideDistX < sideDistY) {
sideDistX += deltaDistX;
mapX += stepX;
side = 0;
} else {
sideDistY += deltaDistY;
mapY += stepY;
side = 1;
}
if (map[mapX][mapY]) hit = 1;
}
if (side == 0) {
perpWallDist = fabs((mapX - raypx + (1 - stepX) / 2) / raydx);
} else {
perpWallDist = fabs((mapY - raypy + (1 - stepY) / 2) / raydy);
}
int lineHeight = abs((int) (h / perpWallDist));
int drawStart = (-lineHeight + h) / 2;
if(drawStart < 0) drawStart = 0;
int drawEnd = (lineHeight + h) / 2;
if(drawEnd >= h) drawEnd = h - 1;
float wallX;
if (side == 1) {
wallX = raypx + ((mapY - raypy + (1 - stepY) / 2) / raydy) * raydx;
} else {
wallX = raypy + ((mapX - raypx + (1 - stepX) / 2) / raydx) * raydy;
}
wallX -= (int) wallX;
int texX = (int) (wallX * (float) (texW));
if(side == 0 && raydx > 0) texX = texW - texX - 1;
if(side == 1 && raydy < 0) texX = texW - texX - 1;
for (y = drawStart; y <= drawEnd; y++) {
int d = (y << 8) - (h << 7) + (lineHeight << 7);
int texY = ((d * texH) / lineHeight) >> 8 ;
int color = tex[texY][texX];
if (side == 1) color = color / 2 ;
setPixelBuf(scrbuf, x, y, color);
}
}
refresh(scrbuf);
}
}
*(unsigned*) 0x900B0000 = 0x00141002;
*(unsigned*) 0x900B000C = 4;
return 0;
}
-
How much FPS does the FAT engine get (so I have an idea of what to aim for)?
I think I'm going to rewrite the engine, since I found a tutorial that seems to be much more like the FAT engine's code.
-
Mhmm, I think the FAT engine gets around 6-10 fps, but I could be wrong. That's what I got from some games at least. Keep in mind FAT engine is very old, though, so idk if it's optimized to maximum. Also most games I tried were not written in pure ASM.
-
Hmm, that is odd about the clock speed. I've never actually set it using C... maybe you need "volatile unsigned" since they are memory-mapped ports.
-
Making it volatile unsigned did the trick. Hooray for 67% more speed!
-
Awesome job again bwang! You're a great coder! :D
150Mh! Wow! ;D
-
nice to hear!
First time I hear of "volatile unsigned", though. I heard about short signed/unsigned, long signed/unsigned, etc, but not that
-
nice to hear!
First time I hear of "volatile unsigned", though. I heard about short signed/unsigned, long signed/unsigned, etc, but not that
Yeah, using "volatile" tells the compiler that it's not normal memory and it must always read/write when told to, rather than optimizing like for normal memory access.
Edit: For example, with code
while (*timer) { };
that waits for a timer register to count down to zero, if "timer" is not specified as volatile, it will only be read once and the read value would be checked against z80 over and over. On the other hand, if it is volatile, it will actually read the register every loop.
-
mhmm I am even more confused x.x, I guess it's stuff that is way too low level for me to understand x.x
-
Wow, that's way over my head. ;) I have so much to learn! ;D
I'm glad it works, though! :D
-
Hmmmm i think i see what is going on, the compiler is very smart, and can see that you are not modifying timer inside the loop, so it assumes that the timer cannot change, and so only checks it once? Crazyness... O.O
-
New demo! This one supports looking up and down (use +/- to do so).
-
wow I wish I could try this but my Nspire has OS 2.0 now. Someone really need to post a batch file to run Goplat's emu easier on Windows, I just can't figure out anything. Else, could someone do a screenshot? (animated, with Calccapture)?
-
Hmmm... would it be legal for me to post an Nspire Emulator image file with Ndless preinstalled?
-
I think so... the emulator is free and Ndless too, so I don't see any problem... Unless it requires a Nspire OS.
-
Mhmm, I am not sure if it would be legal if it includes code from TI. There would be different ways to share it, though, like e-mail.
-
There was a small bug in the previous demo. I attached a new one.
EDIT: Seems like there are more bugs. Should be easy to fix, since the looking up/down code is only 3 lines.
-
Aaah ok ^^
Keep up the good work :)
-
Thanks to bwang for sending me image, I did a screenshot for those who can't install it or don't want to go through the whole process of setting up Goplat emu.
It is friggin epic stuff! I can't imagine how it will look like with complex 16 lv gray textures and stuff in games.
-
OMG! WOW!
That rocks!!!
*cough*Counter-Strike*cough*
-
I finally fixed the looking up/down code, so the bottoms of the walls no longer vanish when you are close to them.
New demo attached.
-
That's awesome! Great work bwang! I'm astonished at how incredible this looks. Great job! ;D
-
I see a very simple multiplayer 3D FPS in the future.
-
Well, that depends on on difficult linking is on the Nspire.
Besides, I don't have sprites yet. That's next on my to-do list!
-
This look AMAZING. Keep up the great work!
-
Multiplayer is not necessary but it might be a plus. Do you think coding AI bots would be easy? That could be another form of multiplayer.
Glad to see an update! I hope eventually you can manage to get the slow downs when close to walls fixed
-
^++
Agreed.
How hard will the engine be in regards to making your own textures?
-
I wonder how hard sprites will be... I guess you'l have to write your own scaling/clipping routine, but sorting would be easy since you already have a z-buffer from the casting you did ^^
-
It seems that per column, sprites take a little bit more work than texture mapping. Whats with the upside-down text?
-
I like april fools :P
-
Lol builderboy, I think this will not show up on every computer (unless I am wrong? I know japaneese chars didn't show well on my old PC)
EDIT: btw bwang I finally decided to upload this on my real Nspire since the Goplat emu wont run at the real speed, and I discovered my old PC had Nspire Compter link software 1.3 (working with Ndless), so I could easily install Ndless fine. It runs pretty sweet on calc, it looks even smoother than on emu too.
Suggestion: I notice it seems you can go really really close to walls. I don't think in FPSes you can go this close to them. Maybe have collision detection done so you won't go as close? It would also reduce the risk of extreme lag.
It is a bit strange, though, because normally in FPSes on the PC, it's when elements that are far away needs to be rendered that the game slows down, not when you're viewing a wall close XD. I guess it's cuz it uses a different algorythm. Anyway I hope you continue working on this. I think this might deserve a major community projects subforum soon if it gets further.
-
When this comes out, I think I may have to put my next project on hold so that I can write a game for this engine! Keep up the good work, so that I can show off your engine's capabilities! ;D
By the way, if you could figure out how to do it, it would be awesome if you could make walls with transparency. It would be a neat feature. I think the only way this would look correct is if the "wall" was rendered like a sprite with a fixed rotation angle, and then rendered in the center of the space for a wall, that way games could use that to make fences or similar barriers that you could see through. I think there would have to be two types of this, one at the horizontal angle, and one at the vertical, so that the engine knew which way to render.
Just a thought I had, I wanted to use something like this in my games before.
Also, do you plan on adding support for different heights of sprites? If so I could make use of your engine's looking up and down feature, by adding a weapon that can shoot up and down as well as left and right. This would end up being probably the most advanced FPS for a calculator that I know of.
Now whether or not I could pull something like that off effectively or not is another matter, but if I can't someone else probably could.
Anyways, I'm pretty much amazed at the quality of your engine, and I can't wait to get my hands on it to see what it can do. Good work!
-
Don't kill DOA, tho :(
-
Not a chance. :)
Who knows, I may decide to just port DOA straight over to the nSpire as my next project, but this time with more functionality.
Also, what's the current resolution of the textures? and do you plan on adding background image support or floor textures or even more epic both?
-
yeah that would be cool, altough a 64 version would still be cool ^^, plus it would show the 68k community is still somewhat not dead ^^
-
I had a version with floor textures a while ago, but I took them out because they were causing a dramatic slowdown (floors need to be textured pixel by pixel, so around 20,000 calculations have to be done per frame to draw them). Different heights of sprites sounds possible, though.
Adding collision detection to stop the player from getting close seems like and excellent idea, now that I know its the norm in most FPSes. I was contemplating this a while ago, but didn't add it because I felt it was a rather hackish way to improve speed.
It is a bit strange, though, because normally in FPSes on the PC, it's when elements that are far away needs to be rendered that the game slows down, not when you're viewing a wall close XD. I guess it's cuz it uses a different algorythm.
On an untextured scene, it would slow down when you see far away elements. But the engine needs to texture more when the columns are closer, which slows it down.
-
I had a version with floor textures a while ago, but I took them out because they were causing a dramatic slowdown (floors need to be textured pixel by pixel, so around 20,000 calculations have to be done per frame to draw them). Different heights of sprites sounds possible, though.
ouch x.x
-
I had a version with floor textures a while ago, but I took them out because they were causing a dramatic slowdown (floors need to be textured pixel by pixel, so around 20,000 calculations have to be done per frame to draw them). Different heights of sprites sounds possible, though.
ouch x.x
Wow. It's too bad; I think floor textures would make this engine almost perfect for everything. ;D
-
Your raycaster engine looks really, really awesome, bwang!
Are you planning to implement columns of variable height?
About the floor and ceiling textures:
Maybe using low resolution for the floor/ceiling textures could reduce the slowdown significantly?
When i see this (and the GB emu) already available for the nSpire i get tempted to buy a nSpire and start program for it :)
-
I think sprites are higher on the priority list right now, and hopefully those can be implemented with good speed left over o.O
-
YES! I got sprites working. The current sprites suck, though (they are only 32x32 with two shades of gray). A nice thing about the algorithm is that the speed does not depend very much on sprite resolution (meaning in theory we can have HUGE sprites). New demo is attached.
Lower resolution textures would not help speed up floor casting, since the algorithm depends only on the number of pixels on the screen. Variable-height columns may be possible.
Why is the forum giving me an error about a file with the same name being present when I try to attach a file named ncaster.tns?
-
Sorry, since Attachments are not encrypted on this SMF board (for easier backup purposes and preventing sad incidents such as TIMGUL), the attachment folder cannot have two files of the same name. It is a forum limitation. I could encrypt them but then it makes backing up much harder since misconfiguration of FTP uploading can lead to data corruption
Just rename the attachment to something else
ANyway gonna give this a try now, I really am curious how it looks like :)
-
Why is the forum giving me an error about a file with the same name being present when I try to attach a file named ncaster.tns?
It anyone's ever uploaded something with the same name, then you can't ever upload anything with that name again. :)
Sounds great! I wish I had a Nspire to try it on! ;D
-
Well backgrounds could be used in place of floor textures, I used that method to make a "floor" in DOA. I can see how the actual floors would be done pixel by pixel, I wonder if there might be another way around this though, like a tile map that was stretched to the perspective of the floor, and then drawn before the walls were drawn. Like a Mode7 engine built into the rendering loop. I wonder if that could be done and make things look real still.
I'm also wishing I had an nSpire right about now, things seem to be getting pretty interesting with them.
-
I tried it and I like the sprite addition ^^
I noticed raycasting is now glitchy when you move camera up/down when being close to walls, though
-
Oops! I was editing the wrong version of the file.
New attachment re-fixes looking up/down.
-
Lol that happens XD
As long as you dont accidentally overwrite a more recent build/backup with older stuff, then it can be bad x.x
EDIT: Nice it works pretty well now ^^
-
I wonder if there might be another way around this though, like a tile map that was stretched to the perspective of the floor, and then drawn before the walls were drawn.
Hmmm...that might actually work. I'll look at that after I fix some sprite-related stuff (such as sprites not moving up and down when you look up and down).
Screenshot:
(http://img580.imageshack.us/img580/4990/screenshotnspireemu.png) (http://img580.imageshack.us/i/screenshotnspireemu.png/)
-
Glad it was fixed ^^
I noticed when trying it that they seemed to act weird when camera was up or down XD
Btw I made a video of the engine in action :)
Sorry for blurriness, my camera batteries were running out x.x
Link
-
Wow! Nice!
/me asks for Counter Strike and goes to buy nspire
j/k
Well, I need money to buy nspire first. It took some time to get enough money before I bought my TI-89 and I'm broke now :P
Good job so far. I love how this is going. Hopefully it leads to more nspire programmer
-
I've been reported a display-bug on an Nspire CAS.
Please watch the video:
http://profile.imageshack.us/user/Levak_92/videos/detail/#189/cimg6977.mp4
-
Glad it was fixed ^^
What was fixed? The sprite issue is still present.
I've been reported a display-bug on an Nspire CAS.
What triggers the bug?
-
Oh wait I misread, I thought you fixed the sprite issue x.x
-
New demo fixes the sprite bug.
-
great! Seems to work pretty fine ^^
One thing, though: I noticed the camera view for up/down seems to be more for a 3rd person style view, for example, from the point where you stand, camera actually seems to go up as you view lower and lower, or vice versa, kinda like if it tried to remain centered on something. It could be very great for a Zelda-like game, but it might be a bit weird for a first person shooter
-
True, the camera does move up and down. I haven't figured out the code to keep it in one place right now (or rather, I haven't tried yet), since I have a bunch of other things to do (optimize sprites, write code to load textures from external bitmaps, bigger sprites, moving sprites, doors, etc.).
-
In the first version with camera moving up/down, it seemed more first-person style, but the walls seemed a bit broken when moving it up or down x.x
I can't wait to see which other stuff you'll come up with :) and screenshots
-
Hmmm...Just realized that the looking up/down code was actually flying/crouching code. That explains the strange effects.
-
o.O
lol, I guess that's explain it then x.x, I didn't knew you had this being implemented XD
It makes me more curious about what this engine will be able to do in the end, actually.
-
Right now I'm not running into any serious hurdles, just a small bug here and there.
I intend to clean up a couple of things and then start on a demo with some gameplay (nothing fancy, just a gun and some enemies to shoot).
-
Is this going to be multiple levels? Also, can we have a good texture for the sky area? Something about just a black ceiling and floor makes it feel really cramped.
-
Right now I'm not running into any serious hurdles, just a small bug here and there.
I intend to clean up a couple of things and then start on a demo with some gameplay (nothing fancy, just a gun and some enemies to shoot).
YES! I can't wait :D
Also I like Netham45 suggestion. The sky should just be 2D imho. In all 3D games you see today, a lot of the backgrounds are kinda 2D too anyway. Basically make it scroll when camera is changing but not when straffing/moving forward/backwards.
Variable wall height would be cool but idk how hard it would be to implement, especially if the floor is texture-less.
-
The floor needs a texutre D:
-
Well, as discussed in previous posts, appearently adding floor textures seems extremly slow.
-
Ah. I only briefly skimmed over the thread, so I missed that.
But, if it's just going to be a generic engine, then how about it's available to the user of the engine?
-
I could make it available, but it wouldn't be much use at all.
Having "fake" floor/sky textures seems like a much better idea. I don't know how good sky textures would look in grayscale, though.
I really want variable wall height, too, but I haven't looked into it yet. Variable wall height really expands possibilities (it changes the levels from Wolfenstein-ish to Doom-ish and allows for stairs, pits, etc).
In case anyone is interested, I've attached a demo with floor textures, so you may see how slow it is.
-
Couldn't a lower resolution speed things up? I don't think people will mind too much to play a game where the 3D is 160x120 scaled up 2x after being used so much to a 96x64 or 160x160 res. The Nspire LCD pixels are so small anyway. Else, if that won't make any speed difference, I guess fake floors might be the best solution. On the FAT engine, sand floors are pretty much just noise and seems pretty random. Else, having the floor not textured but allowing different shades of gray to be chosen based on the map you are on and using fake sky textures could do, too.
It's too bad that it runs slow, because it looks so nice. Else, for a RPG-type game, I think the speed is tolerable, though (people didn't mind Star Fox 10-12 FPSes on the SNES that much anywayanyway). Just probably not for a first person shooter that requires precision when shooting.
-
Yes, the floor texturing actually runs at an acceptable speed at 160x120. I guess I could make screen resolution a user-selectable feature.
-
Having variable height walls would be great.
Years ago, I developped on online raycasting engine in Java.
From my own experience, variable height walls don't slow the engine very much.
Each squared-based-wall had a height and an altitude.
Thanks to the height value, you could climb stairs, walk on walls.
Thanks to the altitude value, you could enter rooms or corridors.
I just used some grey-shaded color for floors and ceilings.
This really transforms the virtual world!
I hope you'll do it.
I do confirm that adding a floor texture (which means floor-casting) was much more time demanding.
-
Yes, the floor texturing actually runs at an acceptable speed at 160x120. I guess I could make screen resolution a user-selectable feature.
great to hear :)
Btw i still think we get too close from walls, maybe make it so we can only move close to a wall as long as we still see 3.5 to 4 rows of bricks? That migth speed things a lil bit more when accidentally getting too close from them. Also, would it be easy to have the floor 160x120 but the rest 320x240? Again, idk how good it will look like.
What I think is that you should maybe make a version with an option menu where we can change resolution for walls/floor/2D ceiling texture, enable/disable each, change the floor color (or ceiling if thee are no texture), etc
@Critor: nice, is that java engine still avaliable online? I am curious how it looks like
-
Looking up/down doesn't work well with the floor.
It produces strange things with sprites too. (doesn't seem natural)
Anyway that's not very important, because when adding variable-height walls, you'll have to rework that code. It may then be easier too...
A little (but more important) bug:
When starting the engine, if you only move forward, you can see that a column of pixels in the middle of the screen remains undrawn.
I'm not criticizing: your work is great.
If you need any help, here is a great tutorial about raycasting.
It's the one I used, years ago.
http://www.permadi.com/tutorial/raycast/index.html
######################
@Omnimaga
Here is my engine -> http://xandrean.free.fr/3dapp/test.html
It has a configuration-screen, like you asked for.
Have fun.
-
Yeah I noticed the floor bug too, I guess he might not have implemented looking up/down for it yet. Btw in the controls It would be nice if we could change the movement speed.
@Critor engine: cool,, I tried it and it was quite fun to mess around with.
(I also merged your double-post)
-
Yeah, I put in the floor code before I added looking up/down, then commented it out, hence the strangeness. I believe the sprites do move up and down when you look up and down, though (and I think its fairly bug-free).
-
yeah sprites appears to work pretty well now :)
-
The progress is amazing, I wish I had an nSpire :( This would be so cool to mess around with.
@critor
Nice Pikachu's throwing PokeBalls ;)
-
Yeah the Pokemon part was funny XD
-
I've been reported a display-bug on an Nspire CAS.
What triggers the bug?
The bug is : When you load it on a TI-Nspire CAS, it doesn't works :)
It is very strange cause it is only the OS which bug, when you load "demo.tns" from Ndless, it works perfectly without this "sticky lag" :D
http://img189.imageshack.us/my.php?image=cimg6977.mp4
-
there must be some OS difference with the CAS that may cause certain programs to not run properly maybe, but again I may be wrong. It's strange, though, considering both the Cas and regular got the same hardware.
(Welcome here btw, Levak)
-
I think a separate build needs to be made for CAS, because the locations of OS routines are different. This is the only reason gbc4nspire needed two builds.
-
Really? I guess I didn't paid attention when gbc4nspire came out x.x. Is it very hard to work around these differences, though?
-
Really? I guess I didn't paid attention when gbc4nspire came out x.x. Is it very hard to work around these differences, though?
When programming in C, all you would have to do is use a different include file for the OS routines
-
I'll upload a CAS version tonight (I can't right now because I'm not on my computer).
critor: what algorithm do you use to draw the tops and bottoms of the boxes when you can see them?
-
Attached is a CAS-compatible demo
-
New slightly changed demo:
* Looking up and down is out for now, in preparation for multi-height walls.
* F key toggles floor textures.
* * and / keys change the resolution.
critor: never mind the floor question, I figured out.
-
mhmm gonna download this now, and try in a few minutes I think. Glad to see more and more progress :)
-
Well, there's not much progress right now--I don't actually have multi-height walls; I'm just changing the code a bit so I can add them later (hopefully in a couple days).
My current plans for the engine (roughly in order of priority):
* Add multiple height walls
* Speed up sprites a bit (so sprites behind you are completely ignored)
* Add doors
* Move code to their own files so that other people can use it
* Add fake sky textures
* Add support for moving objects
* Write external data loader
How does one access files in C on the Nspire?
-
Well I meant in overall there are still new demos every few days, which is whY i said I was happy there was more and more progress.
EDIT: Mhmm bwang, there is a problem with ncaster-0.0.1-noncas.tns . When I run it it reboots the TI-Nspire. I tried the other file too in case you accidentally swapped the names, and same result. I have a TI-Nspire bough in 2009, btw but it's a May 2008 model, as the serial number says (P-0508D)
-
Try the new attachment.
-
Great! it works!
Also did you check if you get a slow down if when in 50% resolution (160x120) or even 25% (80x60) you scale the screen up by 2x or 4x?
(mockups below):
-
I remember scaling a 160x120 up to 320x240 a while ago. It wasn't any slower (because since the ratio is 1:2, I can just fill in 4 pixels for every calculated pixel).
I might render every other column instead of scaling up a half-sized screen, though (so I'd get a 2x increase in speed).
-
Aaah ok. It's up to you I guess. I assumed filling 16 pixels with the same thing wouldn't take much processing power compared to calculting the raycasting for each 16 pixels but I was not sure
-
Attached is a CAS-compatible demo
Thank you for this, but... it doesn't works.
the file make the nspire reboot just after a key enter (instead of the non CAS file which bugs just after loading)
-
Try the new CAS version attached.
-
Will adding multiple tile height be very difficult? That would mean that the ray wouldn't stop at the first tile it reaches, but keeps going until... ? And would it slow down the engine having to draw multiple scaled textures per column?
-
my worry was if you can walk on multiple floors/jump on them, it would get very confusing with the entire floor being a plain color, right? I mean when looking towards a pit, you wouldn't be able to distinguish the bottom floor from the top one
-
Latest trivial update!
Press [Enter] to toggle rendering only every other column (you might have to try a couple times to make it work; the keys don't have any delay so it is possible to switch it on and then off again in one keypress).
@Builderboy:The speed concern is why I have implemented drawing every other column (free 2x speed gain at the cost of a negligibly uglier result).
@DJ Omnimaga: The floors will all be separated by textured walls, so no two floors will ever intersect.
-
aaah ok thanks for info, I'll try this update soon!
EDIT: GAH at Notepad not opening Linux and Mac readmes properly x.x, I hate having to right-click, open with wordpad all the time. Oh well
Btw there's a huge speed increase in lower quality mode and the quality drop isn't too bad. Nice
-
@DJ Omnimaga: The floors will all be separated by textured walls, so no two floors will ever intersect.
What about a higher floor, then a lower floor? Then the textured wall is facing away from you, and cannot be seen. Example from the raycaster I wrote a while back in Python:
(http://i88.photobucket.com/albums/k168/calc84maniac/variableheight.png?t=1270552940)
As you can see, I solved this problem by making the floor a different shade on each level.
-
^I opened this thread, and my jaw dropped until I realized that screenshot wasn't from the TI-Nspire raycaster.
-
@DJ Omnimaga: The floors will all be separated by textured walls, so no two floors will ever intersect.
What about a higher floor, then a lower floor? Then the textured wall is facing away from you, and cannot be seen. Example from the raycaster I wrote a while back in Python:
(http://i88.photobucket.com/albums/k168/calc84maniac/variableheight.png?t=1270552940)
As you can see, I solved this problem by making the floor a different shade on each level.
Yeah that's what I meant, basically. I was worried about that. Would it be slow to rended such floor, even with no floor textures?
@SirCmpwn lol what did you expect? XD It's a gaming consol... er... calculator, after all ;)
-
While it does take a bit of calculations for filling a space with a solid color, it's still much faster than a floor texture due to the fact that you're only calculating the size of the space to be filled and setting those pixels to a color, rather than finding the pixel in the texture for each pixel on the floor, then drawing the corresponding color of the texture to that pixel.
A solid color still requires extra calculations in the engine versus no floor, but it's a better alternative than a textured floor on a platform like this. A creative client programmer can make the resulting game look just as good as with floor textures, by compensating for the less complex image by using more interesting wall textures and more sprite objects in the level to suggest themes for rooms and areas. Plus having a background image will add to the illusion that you are inside, making the space seem larger than it actually is.
Also if the background image scrolls with the player's rotations, the rotation of the walls around the camera will look more realistic.
-
Really trivial update attached changes the quality keys to H and L.
-
Also if the background image scrolls with the player's rotations, the rotation of the walls around the camera will look more realistic.
One thing to make sure is that it also scrolls at a reasonable speed, too. In the past, I saw calc 3D engines where the background scrolled twice slower than you turned around, or at the same speed as far away walls when rotating. It doesn't look much realistic. The background should probably scroll at 1.5x or twice the speed at least
-
Maybe the scrolling could be set by the client program, so that each game could scroll the background as they liked. Plus that could allow a program to use the background to make clouds moving in the distance when the player stood still. It would make programming games for the engine much more programmer friendly.
-
Does anyone have advice/code/pseudocode on how to do multiple height walls? I could use some guidance on how to optimize the feature (I think I have the math right now, but I haven't started implementing yet because it looks messy).
-
Does anyone have advice/code/pseudocode on how to do multiple height walls? I could use some guidance on how to optimize the feature (I think I have the math right now, but I haven't started implementing yet because it looks messy).
The casted ray must not stop at the 1st hitten wall. It has to go through it
With the ray, I'm building a list of objects to display.
Each time the ray hits a wall, I'm adding an object to the list.
Each object consists of its coordinates for the line() function and its color or texture tile.
If we are higher than the top of the wall(or if its texture is transparent), a 2nd object for drawing the top of the wall (floor) is added.
If we are lower than the bottom of the wall (or if its texture is transparent), an object for drawing the bottom of the wall (ceiling) is added
If the texture is transparent, a last object for drawing the back of the wall is added.
The ray stops at the end of the world.
If the world is too big, it may be much slower, when looking far away.
Then I'm drawing objects, from the farthest to the nearest.
So nearer objects are drawn over farther objects, which is natural.
You may then make some optimisations:
- stopping the ray when it is too far (but the effect is not "natural" if you don't add some shading-, fog- or water-effect)
- adding an object to the list, only if it is partially visible (not hidden completly by nearest objects)
- stopping the ray if nothing more can be visible (all pixels from the bottom to the top of the screen have been drawn)
-
New demo!
Walls now have variable heights. Sadly, the floor-drawing code doesn't work (so when you see the top of a cube, bad things happen). Also, the sprite clipping behaves strangely sometimes (since the old 1D Z-Buffer no longer works).
critor: do you have the formulas/source code for drawing the floor segments? I can't seem to figure it out :(
-
Sorry to hear about the issues you got :(
However, this looks FRIGGIN AWESOME! Do you think you could be able to make the lower walls textures not squished vertically? It would look even better
Regardless, I'm saving this on my PC and trying ASAP!
-
However, this looks FRIGGIN AWESOME! Do you think you could be able to make the lower walls textures not squished vertically? It would look even better
Yeah, I had the same thought. I'd imagine it could look pretty bad on very tall walls, too.
-
Or you could simply have a tiling texture that only had a few bricks, and stretched it to fit. That way, it would still stretch a little, but not that bad. Or, you could have it simply cut off at the ends
Don't know how feasible this is...I haven't had much experience with this sort of thing! It Looks awesome, though! Will you be able to stand on lower portions eventually?
-
The textures will tile in the final version.
You will certainly be able to stand on lower walls (after all, what use are stairs if you can't climb them?)
A word of warning: this demo is very buggy. Don't expect too much from it.
-
Or, you could have it simply cut off at the ends
Good call, that's what I'd suggest, since you're drawing wall slices as if they were vertical sprite slices of the wall, clipping in the space provided shouldn't be too much of an issue. You won't have to worry about coding a tiling routine for the textures, they would simply clip to the drawing space you calculated.
I'm pretty much blown away by the way. Quite impressive. I can't wait for this to be completed, my mind is already turning with things I want to do with this engine. *diabolical grin*
-
I tried it and nice despite the bugs. I noticed you made collision detection closer to walls again, though. I still think it should be made at greater distance (seeing 4 or 5 rows of bricks at once at least), like in FPS'es, it would reduce the risks of getting too close to walls and having major slow downs
-
Yum! That screenie looks delicious! ;D
-
Good work, great! :-)
critor: do you have the formulas/source code for drawing the floor segments? I can't seem to figure it out :(
You can get the source of my Java engine, but it may take more time to study it than to build your own algorithm.
When the ray enters a square-wall, if that wall is visible I'm calculating the top and bottom coordinates and drawing the wall.
Those coordinates are kept in the program for being used when the ray exits the square-wall.
When the ray exits the square-wall, I'm calculating those farther top and bottom coordinates, exactly as if I wanted to draw the back of the wall.
If the wall uses a transparent texture, that wall is really drawn.
If the top of the wall is visible, I'm drawing a line between the old and new top-coordinates.
If the bottom of the wall is visible, I'm drawing a line between the old and new bottom-coordinates.
Then of course, by exiting the square-wall, the ray is entering another square-wall.
So I'm looping, drawing the front of the new wall (if visible) again...
-
Ah good, my suggestion wasn't stupid.
So far, the program looks excellent to me. One thing I'm a little confused on:
Mode7 is a floor rendering thing, right? And raycasting is for walls, so combining them gives textured walls, floors and ceilings. Is that right?
How much more power is used by Actual 3D than Raycasting?
-
I wonder if for floors he used Mode 7 but it looked very similar. I know this is what the old F-Zero games, as well as Calc84Maniac 83+ F-Zero clone and F-Zero 68K uses for drawing floors.
-
Yeah. It was also used for Secret of Mana's Overworld map, I believe, as well as FF6's chocobo riding. It kind of gives the isometric feel, but a little better quality with rotation and all.
-
Mode 7 and what I was doing are completely different things. Mode 7 takes a sprite, then distorts it to give an illusion of perspective. I was essentially doing a ray tracing (pixel-by-pixel) pass to draw the floors. I'm thinking about doing Mode 7 to draw floors in the future, though (but that's in the far future, after I squash all the bugs out).
-
True, I also noticed some games uses some sort of masking that makes the planet look round, so it looks like you're very high in the sky. I think Secret Of Evermore did, as well as FFV, but FFV didn't rotate so it isn't fully Mode 7.
Now what I am curious about is if it's possible to have fast Mode 7 on the Nspire? I mean the resolution is similar to the SNES and the SNES can run Mode 7 at 60 FPS. What I wondered is if a SNES can achieve such speed, why wouldn't a Nspire running at 90 MHz be able to do the same?
-
New demo fixes several bugs (most notably, floors). In addition, +/- move the camera up and down.
Sprite clipping is still buggy.
-
oh nice camera moving up/down is back :D
-
Latest demo fixes sprite clipping. Sprites now also move up and down with you.
Next up: sprites and blocks at different altitudes.
-
Wow nice and I noticed a major speed increase when close to walls. Nice job with the floors on top of walls. One only issue, tho: I noticed a very drastic slow down when close to sprites. Some frames even took 10 seconds to render
-
We can has screenshot? :)
-
Well I used a real calc so no screenies but I could post a video of it when I get new batteries
-
The sprites made my nspire crash (it didn't react or extremely slow so I even couldn't use esc). Are the walls infinitely high?
-
You can haz screenshot.
-
Nice! Sprites implemented! and tops for walls!
With Mode7 I don't think I could tell the difference between that and real 3d!
-
The sprites don't crash; they just grow very tall when you get close.
Don't worry, this is easy to fix.
-
great work, bwang! :-)
-
Thanks SirCmpwn.
Keep in mind people that it's not how fast the game run, in Sir screenie, though. Except when close to sprites, I swear I get in the 20-30 fps, based on how fast it runs.
I think this is gonna land in a Major community project sub-forum soon.
-
Wow that's amazing, it looks really good. I've been waiting for something like this. The possibilities are endless! Very nice work. Keep it up. :)
-
The possibilities are endless!
For some reasons, I always get tempted to say Ndless instead of endless when it comes to Nspire stuff :P
-
New trivial update fixes the problems with sprites being slow when you get close.
-
I'm not sure I'd call that trivial, good work! :)
-
Nice to see it fixed :)
Btw, something I noticed when you reduce the screen resolution with * key: if you reduce it way too much, you can no longer resize it up again. In one occasion it resized horizontally only (two versions ago) and my Nspire screen was shifted about 10 or 15 pixels to the left, even outside the raycaster and it lasted until next reboot. And with the previous version when resizing back once the calc rebooted.
-
The resolution changer multiplies the dimensions by 0.9 and then casts them to integers. After a while, the dimensions drop to 0. When you scale them back up again, they stay zero.
The weird problems are probably caused by the dimensions going out of bounds. I'll look at that.
-
aaah Ok ^^
-
The sprites disappear when you 're behind an invisible wall. The other walls don't.
-
Bwang how are you managing the clipping for the sprites? Do you have a full z buffer or what?
-
invisible wall. The other walls don't.
There are invisible walls?
-
My Z-Buffer is still 1-D; that's why the sprites disappear.
I think "invisible wall" means a wall that is intersected by a ray, but is off-screen.
-
oooh ok, maybe he meant that. I'm not too familiar with the 3D/raycasting stuff
-
I mean that, because the variable wall height only applies to graphics, the rest of the wall is invisible and as far I know the walls are infinitely high so a part of every wall is invisible.
-
For some reason, if I make my Z-Buffer a 320x240 array of floats, trying to write anything into it crashes the calculator. Anyone have any ideas why?
phj: no, the walls are not infinitely high internally.
EDIT: This is odder than I thought. Even if I manually check whether the array indices are in-bounds (if (x < w && y < h)...), the program still crashes.
EDIT AGAIN: I had the same problem a while back with a 320x240 array of ints. I also had the same problem with a 320 * 240 1-dimensional array of ints. Should I post source code?
-
You may want to post the source in case certain people may be able to help. SirCmpwn did stuff with C-like languages before and Critor did the java raycaster
-
Source:
#include <os.h>
#include "utils.h"
#include "raymath.h"
#include "sort.h"
#include "sprites.h"
#include "config.h"
asm(".string \"PRG\"\n");
int main(void)
{
*(volatile unsigned*) 0x900B0000 = 0x00000002;
*(volatile unsigned*) 0x900B000C = 4;
struct Sprite sprite[numSprites] =
{
{12, 12},
{13, 12},
{14, 12},
{15, 12},
};
int map[mapWidth][mapHeight]=
{
{0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0},
{0,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,0},
{0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0},
{0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0},
{0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0},
{0,1,0,0,0,0,0,1,1,1,1,1,0,0,0,0,2,2,2,2,2,0,0,0,1,0},
{0,1,0,0,0,0,0,1,0,0,0,1,0,0,0,0,2,0,0,0,2,0,0,0,1,0},
{0,1,0,0,0,0,0,1,0,0,0,1,0,0,0,0,2,0,0,0,0,0,0,0,1,0},
{0,1,0,0,0,0,0,1,0,0,0,1,0,0,0,0,2,0,0,0,2,0,0,0,1,0},
{0,1,0,0,0,0,0,1,1,0,1,1,0,0,0,0,2,2,2,2,2,0,0,0,1,0},
{0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0},
{0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0},
{0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0},
{0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0},
{0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0},
{0,1,0,0,0,0,1,1,1,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0},
{0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0},
{0,1,1,1,1,1,1,1,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0},
{0,1,1,0,1,0,0,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0},
{0,1,1,0,0,0,0,1,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0},
{0,1,1,0,1,0,0,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0},
{0,1,1,0,1,1,1,1,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0},
{0,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0},
{0,1,1,1,1,1,1,1,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0},
{0,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,0},
{0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0}
};
float height[mapWidth][mapHeight]=
{
{0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0},
{0,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,0},
{0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0},
{0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0},
{0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0},
{0,1,0,0,0,0,0,1,1,1,1,1,0,0,0,0,2,1,2,1,2,0,0,0,1,0},
{0,1,0,0,0,0,0,1,0,0,0,1,0,0,0,0,1,0,0,0,1,0,0,0,1,0},
{0,1,0,0,0,0,0,1,0,0,0,1,0,0,0,0,2,0,0,0,0,0,0,0,1,0},
{0,1,0,0,0,0,0,1,0,0,0,1,0,0,0,0,1,0,0,0,1,0,0,0,1,0},
{0,1,0,0,0,0,0,1,1,0,1,1,0,0,0,0,2,1,2,1,2,0,0,0,1,0},
{0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0},
{0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0},
{0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0},
{0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0},
{0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0},
{0,1,0,0,0,0,1,0.8,0.6,0.4,0.2,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0},
{0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0},
{0,1,1,1,1,1,1,1,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0},
{0,1,1,0,1,0,0,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0},
{0,1,1,0,0,0,0,1,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0},
{0,1,1,0,1,0,0,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0},
{0,1,1,0,1,1,1,1,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0},
{0,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0},
{0,1,1,1,1,1,1,1,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0},
{0,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,0},
{0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0}
};
char* scrbuf = (char*) malloc(SCREEN_BYTES_SIZE);
int tex[texW][texH];
int u, v;
for (u = 0; u < texW; u++) {
for (v = 0; v < texH; v++) {
tex[u][v] = 6;
}
}
for (u = 0; u < texW; u++) {
for (v = 0; v < texH; v++) {
if (u % 4 == 3 || (v % 8 == 2 && ((u / 4) % 2) == 0) ||
(v % 8 == 6 && ((u / 4) % 2) == 1)) {
tex[u][v] = 15;
}
}
}
int tex2[texW][texH];
for (u = 0; u < texW; u++) {
for (v = 0; v < texH; v++) {
tex2[u][v] = (u ^ v) / 2;
}
}
int texSpr[texW][texH];
for (u = 0; u < texW; u++) {
for (v = 0; v < texH; v++) {
int dsq = (u - 16) * (u - 16) + (v - 16) * (v - 16);
if (dsq > 196 && dsq < 256) {
texSpr[u][v] = 0;
} else if (dsq < 196 && dsq > 64) {
texSpr[u][v] = 8;
} else if (dsq < 64 && dsq > 49) {
texSpr[u][v] = 0;
} else {
texSpr[u][v] = -1;
}
}
}
float posX = 12, posY = 12;
float dirX = -1, dirY = 0;
float planeX = 0, planeY = 0.66;
int w = 320, h = 240;
int res = 1;
int x, y;
float zbuf[w][h];
int spriteOrder[numSprites];
float spriteDistance[numSprites];
int redraw;
float heye = 0.5;
while (!isKeyPressed(KEY_NSPIRE_ESC)) {
redraw = 0;
if (isKeyPressed(KEY_NSPIRE_LEFT)) {
float oldDirX = dirX;
dirX = dirX * cos1 - dirY * sin1;
dirY = oldDirX * sin1 + dirY * cos1;
float oldPlaneX = planeX;
planeX = planeX * cos1 - planeY * sin1;
planeY = oldPlaneX * sin1 + planeY * cos1;
redraw = 1;
}
if (isKeyPressed(KEY_NSPIRE_RIGHT)) {
float oldDirX = dirX;
dirX = dirX * cos1 + dirY * sin1;
dirY = -oldDirX * sin1 + dirY * cos1;
float oldPlaneX = planeX;
planeX = planeX * cos1 + planeY * sin1;
planeY = -oldPlaneX * sin1 + planeY * cos1;
redraw = 1;
}
if (isKeyPressed(KEY_NSPIRE_UP)) {
if (map[(int) (posX + stpsize * dirX)][(int) (posY)] == 0)
posX += stpsize * dirX;
if (map[(int) (posX)][(int) (posY + stpsize * dirY)] == 0)
posY += stpsize * dirY;
if (posX < 0) posX = 0;
if (posX > 24) posX = 24;
if (posY < 0) posY = 0;
if (posY > 24) posY = 24;
redraw = true;
}
if (isKeyPressed(KEY_NSPIRE_DOWN)) {
if (map[(int) (posX - stpsize * dirX)][(int) (posY)] == 0)
posX -= stpsize * dirX;
if (map[(int) (posX)][(int) (posY - stpsize * dirY)] == 0)
posY -= stpsize * dirY;
if (posX < 0) posX = 0;
if (posX > 24) posX = 24;
if (posY < 0) posY = 0;
if (posY > 24) posY = 24;
redraw = true;
}
if (isKeyPressed(KEY_NSPIRE_MINUS)) {
heye -= 0.1;
redraw = true;
}
if (isKeyPressed(KEY_NSPIRE_PLUS)) {
heye += 0.1;
redraw = true;
}
if (isKeyPressed(KEY_NSPIRE_DIVIDE)) {
w = (int) (w * 1.1);
if (w > 320) w = 320;
h = (int) (h * 1.1);
if (h > 240) h = 240;
redraw = true;
}
if (isKeyPressed(KEY_NSPIRE_MULTIPLY)) {
w = (int) (w * 0.9);
h = (int) (h * 0.9);
redraw = true;
}
if (isKeyPressed(KEY_NSPIRE_H)) {
res = 1;
redraw = true;
}
if (isKeyPressed(KEY_NSPIRE_L)) {
res = 2;
redraw = true;
}
if (redraw) {
memset(scrbuf, 0x00, SCREEN_BYTES_SIZE);
for(x = 0; x < w; x += res) {
float rayPosX = posX;
float rayPosY = posY;
int mapX = (int) rayPosX;
int mapY = (int) rayPosY;
float cameraX = 2 * x / (float) (w) - 1;
float raydx = dirX + planeX * cameraX;
float raydy = dirY + planeY * cameraX;
float sideDistX;
float sideDistY;
float raydx2 = raydx * raydx, raydy2 = raydy * raydy;
float deltaDistX = sqrt(1 + raydy2 / raydx2);
float deltaDistY = sqrt(1 + raydx2 / raydy2);
float perpWallDist;
int stepX;
int stepY;
int side;
float curH = 0;
int scrtop = h - 1;
if (raydx < 0) {
stepX = -1;
sideDistX = (rayPosX - mapX) * deltaDistX;
} else {
stepX = 1;
sideDistX = (mapX + 1.0 - rayPosX) * deltaDistX;
}
if (raydy < 0) {
stepY = -1;
sideDistY = (rayPosY - mapY) * deltaDistY;
} else {
stepY = 1;
sideDistY = (mapY + 1.0 - rayPosY) * deltaDistY;
}
int first = true;
while (mapX > 0 && mapX < mapWidth && mapY > 0 && mapY < mapHeight ) {
if (sideDistX < sideDistY) {
sideDistX += deltaDistX;
mapX += stepX;
side = 0;
} else {
sideDistY += deltaDistY;
mapY += stepY;
side = 1;
}
if (!map[mapX][mapY]) continue;
if (scrtop < 0) break;
float hwall = height[mapX][mapY];
if (side == 0) {
perpWallDist = fabs((mapX - rayPosX + (1 - stepX) / 2) / raydx);
} else {
perpWallDist = fabs((mapY - rayPosY + (1 - stepY) / 2) / raydy);
}
int nextX;
int nextY;
int nextSide;
if (sideDistX < sideDistY) {
nextX = mapX + stepX;
nextSide = 0;
} else {
nextY = mapY + stepY;
nextSide = 1;
}
float nextD;
if (nextSide == 0) {
nextD = fabs((nextX - rayPosX + (1 - stepX) / 2) / raydx);
} else {
nextD = fabs((nextY - rayPosY + (1 - stepY) / 2) / raydy);
}
int lo = (int) (h * (0.5 - heye / perpWallDist));
int lw = (int) (h * hwall / perpWallDist);
int nlo = (int) (h * (0.5 - heye / nextD));
int nlw = (int) (h * hwall / nextD);
int fstart = h - nlo - nlw;
int fend = h - lo - lw - 1;
int wstart = h - lo - lw;
int wend = h - lo - 1;
float wallX;
if (side == 1) {
wallX = rayPosX + ((mapY - rayPosY + (1 - stepY) / 2) / raydy) * raydx;
} else {
wallX = rayPosY + ((mapX - rayPosX + (1 - stepX) / 2) / raydx) * raydy;
}
wallX -= (int) wallX;
int texX = (int) (wallX * (float) (texW));
if(side == 0 && raydx > 0) texX = texW - texX - 1;
if(side == 1 && raydy < 0) texX = texW - texX - 1;
//floor loop
int y;
int sfstart = max(fstart, 0);
int sfend = min(fend, scrtop);
for (y = sfstart; y <= sfend; y++) {
setPixelBuf(scrbuf, x, y, 8);
//very large value since sprites always cover floors
zbuf[x][y] = 1000;
if (res == 2 && x < w - 1) {
setPixelBuf(scrbuf, x + 1, y, 8);
zbuf[x + 1][y] = 1000;
}
}
//wall loop
float texY = 0;
float texD = ((float)texH) / ((float)lw);
int swstart = max(wstart, 0);
if (swstart == 0) texY += (-wstart) * texD;
int swend = min(wend, scrtop);
for (y = swstart; y <= swend; y++) {
int color = tex[(int) texY][texX];
if (side == 1) color = color / 2;
setPixelBuf(scrbuf, x, y, color);
//set the zbuffer
zbuf[x][y] = perpWallDist;
if (res == 2 && x < w - 1) {
setPixelBuf(scrbuf, x + 1, y, color);
zbuf[x + 1][y] = perpWallDist;
}
texY += texD;
}
int oldtop = scrtop;
scrtop = fstart - 1;
if (scrtop > wstart - 1) scrtop = wstart;
if (scrtop > oldtop) scrtop = oldtop;
curH = hwall;
}
}
int i;
for(i = 0; i < numSprites; i++)
{
spriteOrder[i] = i;
spriteDistance[i] = ((posX - sprite[i].x) * (posX - sprite[i].x)
+ (posY - sprite[i].y) * (posY - sprite[i].y));
}
combSort(spriteOrder, spriteDistance, numSprites);
for(i = 0; i < numSprites; i++)
{
float spriteX = sprite[spriteOrder[i]].x - posX;
float spriteY = sprite[spriteOrder[i]].y - posY;
float invDet = 1.0 / (planeX * dirY - dirX * planeY);
float transformX = invDet * (dirY * spriteX - dirX * spriteY);
float transformY = invDet * (-planeY * spriteX + planeX * spriteY);
int spriteScreenX = (int) ((w / 2) * (1 + transformX / transformY));
#define uDiv 1
#define vDiv 1
#define vMove 0.0
int vMoveScreen = (int) (vMove / transformY);
int spriteHeight = abs((int) (h / transformY)) / vDiv;
int lo = (int) (h * (0.5 - heye / transformY));
int drawStartY = h - lo - spriteHeight;
int drawEndY = h - lo;
if (drawEndY > h - 1) drawEndY = h - 1;
int texOff = 0;
if (drawStartY < 0) {
texOff = -drawStartY;
drawStartY = 0;
}
int spriteWidth = abs((int) (h / (transformY))) / uDiv;
int drawStartX = -spriteWidth / 2 + spriteScreenX;
if(drawStartX < 0) drawStartX = 0;
int drawEndX = spriteWidth / 2 + spriteScreenX;
if(drawEndX >= w) drawEndX = w - 1;
int stripe;
float texD = ((float)texH) / ((float)spriteHeight);
texOff *= texD;
for(stripe = drawStartX; stripe < drawEndX; stripe += res)
{
int texX = (int) (256 * (stripe - (-spriteWidth / 2 + spriteScreenX)) * texW / spriteWidth) / 256;
float texY = texOff;
if(transformY > 0 && stripe > 0 && stripe < w) {
for(y = drawStartY; y < drawEndY; y++)
{
if (y >= 0 && y <= h - 1) {
if (transformY >= zbuf[stripe][y]) continue;
int color = texSpr[(int)texY][texX];
if (color != -1) {
setPixelBuf(scrbuf, stripe, y, color);
if (res == 2 && stripe < w - 1) {
setPixelBuf(scrbuf, stripe + 1, y, color);
}
}
}
texY += texD;
}
}
}
}
refresh(scrbuf);
}
}
*(volatile unsigned*) 0x900B0000 = 0x00141002;
*(volatile unsigned*) 0x900B000C = 4;
return 0;
}
-
You may want to post the source in case certain people may be able to help. SirCmpwn did stuff with C-like languages before and Critor did the java raycaster
I have worked with high-level C# and z80 assembly, and have never done raycasting. I am flattered you think I can help, though.
-
aaah ok ^^
-
bwang, any time you write data to floats, if you write integer type values like
float var;
var = 1;
then the compiler could possibly see 1 as an integer and tries to treat "var" as such.
try something like this instead
float var;
var = 1.0;
C can be very frustrating in that regard.
I really didn't see anything else that stuck out to me why it would only happen when you changed datatypes though.
Also, I had great difficulty following parts of your code at first, it would really help me if you went through and commented sections of your code describing what each chunk is supposed to accomplish, so that I may be able to spot whats going on.
Good job so far with what you're doing. If you want me to look at anything else then please let me know. You can pm me with code snippets and general questions and such. Good luck.
-
It didn't work when the data was ints, either.
EDIT: I will post some commented code on Monday, as I am a bit busy right now.
-
I may have found the issue, I don't know for sure though.
in this section of code,
for (y = sfstart; y <= sfend; y++) {
setPixelBuf(scrbuf, x, y, 8);
//very large value since sprites always cover floors
zbuf[x][y] = 1000;
if (res == 2 && x < w - 1) {
setPixelBuf(scrbuf, x + 1, y, 8);
zbuf[x + 1][y] = 1000;
}
}
you are testing if the "res" variable is equal to 2 after you assign a value to "zbuf", which is addressed with the var "x" which is incremented by res, so potentially, if you're incrementing by two, you could possibly step out of the bounds of the array, maybe if you restructure it like so:
for (y = sfstart; y <= sfend; y++) {
//very large value since sprites always cover floors
if (res == 2 && x < w - 1) {
// i did it this way because it appears that you're wanting it to set the z buffer and the pixelbuf thingy at both x and x+1 on res == 2
setPixelBuf(scrbuf, x , y, 8);
zbuf[x][y] = 1000;
setPixelBuf(scrbuf, x + 1, y, 8);
zbuf[x + 1][y] = 1000;
}
else if (res == 1 && x < w) // it only seems to be either or, but I decided to use an else if in case it wasn't
{
setPixelBuf(scrbuf, x , y, 8);
zbuf[x][y] = 1000;
}
}
You do something similar here:
for (y = swstart; y <= swend; y++) {
int color = tex[(int) texY][texX];
if (side == 1) color = color / 2;
setPixelBuf(scrbuf, x, y, color);
//set the zbuffer
zbuf[x][y] = perpWallDist;
if (res == 2 && x < w - 1) {
setPixelBuf(scrbuf, x + 1, y, color);
zbuf[x + 1][y] = perpWallDist;
}
texY += texD;
}
I would change it in the same manner as the one above:
for (y = swstart; y <= swend; y++) {
int color = tex[(int) texY][texX];
if (side == 1) color = color / 2;
//set the zbuffer and the pixel buffer
if (res == 2 && x < w - 1) {
// same as above, I assumed that you wanted to set both x and x+1 in the pixelbuffer thingy and the zbuffer.
setPixelBuf(scrbuf, x, y, color);
zbuf[x][y] = perpWallDist;
setPixelBuf(scrbuf, x + 1, y, color);
zbuf[x + 1][y] = perpWallDist;
}
else if (res == 1 && x < w)
{
setPixelBuf(scrbuf, x, y, color);
zbuf[x][y] = perpWallDist;
}
texY += texD;
}
Seeing as you're only adjusting the variable "zbuf" at two points in your code, I think these two places are going to be where the problem lies.
hope this helps.
-
Lionel Debroux suggested here (http://www.unitedti.org/forum/index.php?showtopic=9348) that I allocate zbuf with malloc. It kind of works (see last post on UTI thread).
-
Aaah ok ^^
Good luck!
-
I'm not really sure why that would work, but if it does I guess roll with it. You said it "kind of works" what do you mean by kind of?
-
It doesn't crash, but doesn't give correct results either. I'm probably doing something wrong when putting values into zbuf.
-
Sprite clipping fixed! New demo attached.
-
Cool glad to hear ^^
-
It looks awesome :) can't wait to see it run on hardware ^^
-
What I would like to see next out of this is collision detection with variable-height walls and the current player height. I shouldn't be stopped by an invisible wall that is just an extention of the one below me, right?
-
yeah I would like that. I wonder how hard it would be to implement?
-
Nearly trivial, but that's low on my priority list. I want to re-organize the code to make it usable as a graphics engine right now. Collision detection and such would be handled by the client program.
-
Would he need to code them himself? Or would he just need to turn on/off some stuff?
-
I think the writer of the client program should write their own collision detection routines, the reason being some games might want custom routines (walk through walls, physics, etc.)
-
This program is incredible! Keep up the awesome work bwang! ;D
-
I smell a 3D portal clone for the nSpire ;) Haha Bwang will you give support for custom textures? What other features do you have planned?
-
I think the writer of the client program should write their own collision detection routines, the reason being some games might want custom routines (walk through walls, physics, etc.)
Aaah ok, I think it would be cool if some people could write routines for others, though, so people can easily do games without having to code much. Some sort of game maker.
and a portal clone for Nspire would be cool. Wouldn't that be hard with raycasting, tho?
-
Heh probably amazingly impossible hard ;D I'll leave it to Bwang to add in multidimensional warping support in later versions ;)
-
The main issue i thought about is trying to view the floor at parralel angle, which may seem weird in raycasting, especially when close to walls. Try Duke Nukem 3D with no mods and look up near buildings. Idk if DN3D is raycasting, but look at the lack of perspective for walls when viewing up/down
-
I dont think DN3D was a raycaster.
-
I dont think DN3D was a raycaster.
Knowing how RayCasting looks like and works, I think DN3D was using a raycaster.
If bwang implements walls at variable altitudes, we can start building doors, corridors, bridges, rooms and so make the virtual world looks like in DN3D.
-
That would really rule. I guess there would still be the issue of the floor being slow rendering, right?
-
I could always render the floor at a very low resolution, or cheat and use an image.
-
low res could work. Maybe every 4 vertical lines?
-
I could always render the floor at a very low resolution, or cheat and use an image.
Using an image for the sky (background - vertical) can give a realistic effect.
But it's not the same thing for the floor...
Unless your image is very simple, it won't look realistic while moving, especially while rotating.
-
Btw I just tested last version and nice work again. I notice a speed increase in sprite display.
-
If bwang implements walls at variable altitudes, we can start building doors, corridors, bridges, rooms and so make the virtual world looks like in DN3D.
I've been puzzling about this and thinking whether I should add it. On one hand, the worlds would look a lot nicer. On the other hand, implementing walls at variable altitudes is non-trivial, and without supporting features (such as the ability to look up at the ceiling), would not add much to gameplay, not to mention adding a bit more overhead (although not much) to the main rendering loop.
What do you guys think? What should I add next? I'm thinking doors and multidirectional sprites.
-
doors would be cool. What would be multi directional sprites, though? do you mean moving objects/enemies?
-
Sprites that turn when you turn.
-
i am even more confused now x.x
-
You know how no matter where you are in the map, the donuts always face you? And if they were enemies, they would always face you as well. What bwang is proposing is changing the sprite depending on where you are so that the sprite always looks like it is facing the same direction.
-
oooh I see now x.x thanks for clarifying
-
Yeah thats the tricky thing about 3D games that dont have 3D modeling, you have to cheat a bit with the enemies and objects. Luckily there is no looking up or down so it makes it a lot easier.
-
I'm not so sure that the effect of walls at different heights would be lost if you can't look up and down, the original doom featured this but didn't have the ability to look up and down.
-
I thought it did? I remember looking up/down in Doom PC before, or maybe it was Doom 2?
-
No, it didn't. I remember playing the wii port, and being annoyed I couldn't shoot at the guy standing on a higher platform. However, the different height walls were still very nice. Maybe there could be an aiming mechanism that doesn't require camera movement, eg. moving crosshair at buttonpush, but movement when not pushed
-
In the original doom, if you were aiming in the direction of an enemy on a higher platform, you would shoot at that enemy. It may be different on the wii port, but on the original pc game that's how it was IIRC.
Bwang, how is it going with the multidimensional sprites?
-
They are multidirectional sprites, not multidimensional.
I'm really busy right now (the USA Math Olympiad is on Tuesday and I have to study for it). There will be faster progress starting next Thursday.
-
In the original doom, if you were aiming in the direction of an enemy on a higher platform, you would shoot at that enemy. It may be different on the wii port, but on the original pc game that's how it was IIRC.
Bwang, how is it going with the multidimensional sprites?
I guess I was confused because on the PC I played mostly the mod that enhanced gameplay and graphics. I only played the original about once or twice because it ran very slow on my 2.93 GHz PC running Windows XP and I was too lazy to install DOSbox
-
Yeah, the newer source ports like Doomsday supported looking up and down.
Strange that original Doom ran slowly on your XP machine though. Did you try a source port like PrBoom?
-
Nah it was the original Demo. the problem is that it was using DOS I think, and XP has horrible DOS emulation, so many old DOS games will run horribly on XP machines, which is why many people rely on DOSbox to play them.
-
Haha I made a typo when posting, I meant to say multidirectional. :P I had the same problem as kev, also some old dos games simply won't run on windows XP because of a change in the way XP's dos handling handles certain math functions. I had an old raycasting game called Iron Assault, and it wouldn't run or anything unless you configured XP's dos emu with a special setting, or used dosbox.
Bwang, good luck with your studies, that always comes first. No matter how epic a project you may be working on for a calc. ;D
-
Heh, usually when i get into AP testing or finals, i accidentally spend a lot of time away from the cimputer, cooped up in a study session, and coding some new and fun things ;D Haha im so bad, i should get back to studying.
-
/me inserts a rickroll in Builderboy's calc that won't go off until he finishes his school work (altough it lets the calc turn off to save on batteries)
-
New update!
Added walls at variable altitudes.
Sprite clipping is a bit broken again.
-
nice to see progress, unfortunately I won't be able to play anymore, tho, cuz I now have OS 2.0.1 on my Nspire since I needed a no-power-management-bug OS in 84+ mode, and I never got able to get Ndless to work on Goplat's emu, even after help.
-
Have a screenshot, then.
-
wow looks nice, I ddiN,t thought you had variable wall bottom, I didnt knew you meant that in your post. Awesome!
Can we go under them yet?
-
Hey thats awesome!
DJ: I can help you get ndless working in the emu, the same way i got it going :).
(ill be on when i get home tonight).
-
Oh someone got me a copy with everything setup for me, cuz I just couldnt figure out even after getting help from someone before. Command prompt is just not my thing.
Anyway thanks to that person, I got an animated screenshot now
-
Wow this has to be the most impressive raycasting I've seen on a calculator yet. Good work Bwang. I can't wait for this project to be released. It could be the reason I end up buying an nSpire.
-
Small update attached fixes sprite clipping again.
-
Very nice :)
-
Wonderfull, Bwang!
You've pushed the raycasting algorithm beyond its limits.
Congratulations!
It's not raycasting any more... It's Extended RayCasting!
-
Wonderfull, Bwang!
You've pushed the raycasting algorithm beyond its limits.
Congratulations!
It's not raycasting any more... It's Extended RayCasting!
I was tempted to say ExtendeD ;D (altough that might have sounded like if I thought ExtendeD wrote the raycaster)
-
@DJ Omnimaga: may I ask why you chose "tru895698uitui4ui5ui.gif" as the gif's name? :P
-
Because I got sick to death of the duplicate attachment names bug on the forums and even if I tried an unconventional name for it before, I still got the error anyway, so I got pissed and typed random crap as file name.
-
Does anyone have advice on file access functions on the Nspire? Are the standard ones present?
-
My guess is yes if it talking about the computer stadard
-
New demo! Thanks to this (http://ti.bank.free.fr/index.php?mod=archives&ac=voir&id=1630), I was able to import some textures and sprites, so the demo looks a lot nicer now.
-
O.O
83489389578333883489772378578957895478954789457892348243892258988958585892458988954899289458457854783578534254
i ALMOST had an heart attack x.x
It looks really great in 16 gray depth :D
Keep up the good work
btw is the shading on certain walls done automatically?
-
btw is the shading on certain walls done automatically?
Yes, one side is automatically darker than the other.
-
Cool :D
Also are you planning to add tiled texture support soon? (so they aren't distorted on different height walls)
-
wow stunning work. I can't believe what this thing is capable of! ;D
-
I did an animated screenshot
-
New demo. The textures now tile on the tall columns.
-
I made a screenshot and 4 mins later he posts an update D:
j/k glad to see one lol
Do you think you could make the textures tile starting from the bottom of the wall instead of top, though? It might look nicer
-
Oops, I missed that bug. Fixed.
-
yay :D
-
Wow, those new textures/sprites look fantastic! My proverbial mouth is watering at these images! :D
-
New demo. You can now climb stairs and go under floating blocks, and sprites now have a z-coordinate. As such, +/- to move up and down has been removed, and the map has been changed to demonstrate the new features.
Next up is different wall textures for different blocks, and different sprites.
-
oooh great! Nice to see new stuff being added :) Keep up the good work!
-
Here's an avi of the emulator, for those who don't have Nspires.
For some reason, if I convert the avi to a gif, it grows to ~20 MB, so I can't upload a gif.
The engine on real hardware is smoother than what you see in the video (its 60 Mhz faster, and Wine makes the emulator a bit choppy).
-
wow that's great! :O
And yeah I hate how gifs gets pretty huge sometimes, especially with Nspire stuff x.x
AVIs can be compressed easier and still look decent. Nice job on the raycaster :)
-
Sweet, downloading the new version now!
-
Every time a new video is posted, I want to try this more and more, but I have OS 2.0 and I need the programming tools in 2.0 for Chemistry programs I use in school. I wish this would work on 2.0. :( I hope Ndless 2 comes out soon.
-
Me too. I hope once school ends, that there will be some progress. Else after June there's no sign of life, I'll get worried x.x
(End of school == busy with exams. Once exams and school is over == more free time. However, if no progress despite increased free time, it means the author lost interest or got in serious trouble with TI)
-
New demo!
This one adds support for different textures and sprites.
I think the engine is nearly ready for a real release. I've split all the rendering code out of the main program, so essentially the engine consists of one render() function that takes map data, sprite data, texture data, camera position, and a screen buffer as parameters and draws the rendered image to the buffer.
I'm worried about the speed now, though. It becomes a bit choppy when you're looking at a complex scene :(
-
I really like the way you've handled that, it makes it much easier to use the same screen buffer to put stats and such on the screen as well as the rendered scene. If you want to I could try to help you optimize the code to make it faster. Also are you going to keep the variable viewing screen size in the finished program? If you are, the client code could adjust the viewing area to meet it's own processing needs. That way, games with more complicated AI and such would be able to make up for the processing time for that by decreasing the screen size. It would make your engine extremely flexible.
-
Holy fuck, Doom-era games on an Nspire, nice job
-
This looks incredible! As always, nice job bwang! ;D
-
I really like the way you've handled that, it makes it much easier to use the same screen buffer to put stats and such on the screen as well as the rendered scene. If you want to I could try to help you optimize the code to make it faster. Also are you going to keep the variable viewing screen size in the finished program? If you are, the client code could adjust the viewing area to meet it's own processing needs. That way, games with more complicated AI and such would be able to make up for the processing time for that by decreasing the screen size. It would make your engine extremely flexible.
I'll make a release with source in a bit, once I extract all my stuff from the Ndless folder I've been coding this in.
The adjustable screen size is part of the engine right now; render() takes the width and height of the screen as two of its parameters.
-
Nice to see it's getting close to engine release! Also with the source some other people might be able to help in the community, especially if on ticalc.org. Just make sure that instructions on how to use it won't be too cryptic, though, for the average C programmer/Windows user.
-
render() takes the width and height of the screen as two of its parameters.
Are you also able to set where on the screen buffer the viewing area is rendered? Also if you make a structure out of your parameters for the rendering engine, it could speed up the engine a bit, because you'd be actually passing one void pointer to the function, like so:
typedef struct
{
int screen_width,
int screen_height,
//pointer to sprite array, however that's defined//
// same for texture array//
int screen_position_x,
int screen_position_y
// etc//
}
render_structure;
render_structure rend_struct;
render(rend_struct);
This way when you pass rend_struct, C actually sees rend_struct as a pointer to a place in memory, and you're actually only passing one void pointer through the stack, which if I'm not mistaken is only one char.
-
Are you also able to set where on the screen buffer the viewing area is rendered?
I'll add that feature.
The structure for the parameters sounds like a good idea, especially since it makes render() a bit easier to use (no need to remember what order the parameters come in).
-
how much does this strain the cpu?
-
This looks amazing. I want to learn C just to try out the engine :)
-
how much does this strain the cpu?
I get 10-30 FPS at 320x240 rendering every other column. The framerate greatly depends on the complexity of the scene being rendered. Bridges and tunnels, in particular, really push the engine.
-
I moved this to its own sub-forum right under Axe parser and CaDan in Major TI community projects.
-
This continues to look impressive. I won't be able to fool around with it for a while yet as I don't own a Nspire. I'm wait for ndless 2 before I get one.
-
YAY for version 0.2.0, didn't expect to come out immediately :O
Btw you can lock your own topics. Above the Quick Reply there are a few options and Lock topic should be there. This should prevent non-staff from posting in it. Also I think you can still post in it if it's locked because Quigibo can with Axe Parser.
-
YAY for version 0.2.0, didn't expect to come out immediately :O
Why ?
-
YAY for version 0.2.0, didn't expect to come out immediately :O
Why ?
I did not mean this in a bad way, I was just amazed at how incredibly quick he worked on this project. No need to jump on me
-
YAY for version 0.2.0, didn't expect to come out immediately :O
Why ?
I did not mean this in a bad way, I was just amazed at how incredibly quick he worked on this project. No need to jump on me
I'm not jumping on you.
Sorry, I've misunderstood...
I thought you were talking about Ndless2.
For various reasons, I'm not expecting Ndless2 to come out soon...
-
exams, studies, school projects, and the jump straight from version 0.1.0 to 0.2.0 suggests me a lot was added since 0.1.0, meaning it could take a while to add.
Notice how the board overall post rate went down by 100 posts a day approximately. Most people are busy with school exams atm, since it's May, projects have a slower progress rate and some members post less often, which is an indication that they have much less free time. This is why I was amazed at the speed at which Bwang worked on 0.2.0.
If those reasons are not valid for you, then I am sorry, but I did not mean anything wrong in my reply to version 0.2.0 release. I am entitled to my opinion, though, which is based on my 9 years of experience in the TI community (I saw many projects in the works and the rate at which they progress depending of the time of the year)
-
If those reasons are not valid for you, then I am sorry, but I did not mean anything wrong in my reply to version 0.2.0 release. I am entitled to my opinion, though, which is based on my 9 years of experience in the TI community (I saw many projects in the works and the rate at which they progress depending of the time of the year)
I was not meaning anything wrong either...
To your advice, do the same reasons apply to Ndless development, or is there anything else?
(it's strange as YaroNet which was the greatest forum about Nspire hardware information and exploits, has been silent for over a month...)
-
Yeah I guess it would apply to Ndless.
Also, three other factors can cause a project to die or slow down a lot in the TI community: lack of interest, quitting calc programming completly/moving on to other stuff or the person getting in trouble. I hope the later did not happen to Geogeo and ExtendeD with TI, altough I doubt ExtendeD got into serious trouble, if any, since he still shows up from time to time in the online list here (about once a week). As for moving on, I doubt this happened with those two people, noticing their dedication to the calc community since 2004-05, but we never know. I've been browsing TI sites since 2001 and I must tell you: when somebody stays around programming for longer than one year without losing interest, it's a miracle. A project can see loads of updates for a while, then suddently, one day, the author vanishes completly, leaving no more sign of life for months, then returning to say the project is discontinued and he is releasing the source. In some cases it's even worse, the author vanishes and never return (see RevSoft hosting).
(About your yAronet comment, yeah I found it very strange. Same for UTI. I would have expected UTI to continue getting a lot of traffic for the Nspire and key factoring stuff. Again, their downtimes and some other issues might have influenced UTI activity, though.)
-
The jump from 0.1.0 to 0.2.0 is to signify the change from demo/alpha to beta status. Nothing new was added; I just rearranged the source a lot.
-
Oh, ok x.x
Are you plannign a ticalc release, btw?
-
Soon, after I fix a couple of things and write some documentation.
-
Aaah ok good to hear :)
-
I had a really cool idea. While the engine, like most raycasters, doesn't support 3d models, it does support Sprites that can be viewed from different angles, right? Using that, we could create simplistic 3D objects by making sprites that line up at the corners. Sure, it couldn't make a Person or anything fancy, but it could make boxes or other flat shapes.
Is this impossible? I don't know too much about the sprites and such with raycasting.
-
Sprites facing different directions (angle-wise) would be cool, or 3D sprites in the style of the Nintendo 64
-
Multidirectional sprites are quite possible, and I intend to add them in the future. However, they are precomputed, so you can't have a box made of sprites.
-
Will it be possible to have sprites stacked like this, though?
If you notice in 3D games, in most cases, the trees aren't really fully 3D models, the leaves are stacked 2D sprites set at different angles, to make the tree leaves look like 3D.
-
that's exactly what I was talking about, DJ!
Good to know! by precomputed, do you mean they're immobile? Won't that cause problems with movements of enemies?
-
@DJ: Yes. In fact, that (and multidirectional sprites) are already possible; the client just needs to update the sprites being drawn based on the camera direction.
@willrandship: No, not immobile. What I mean is that the images being drawn views of a 3D object from different angles. When you "turn" the sprite, you look up what image will be drawn based on the angle.
-
Aah sounds cool, and how many sprites does the engine support in one map?
-
As many as you want, limited by only memory and speed considerations.
-
AAh ok. Thanks ^^
-
I've always wondered if there was a way you could have a sub class of sprites in a ray caster that didn't stay perpendicular to the camera, who's orientation would be set, and therefore would be stretched according to perspective like a wall. This would come in handy because it would be flat and have transparency, allowing for objects like a chain link fence or iron bars blocking a path. Would this be easy to do? I only know the very basics of ray casting, and only in the context of a fixed angle ray caster.
-
The algorithm I'm using can support transparent wall textures with a little modification. I'll add that in the next release.
-
:O
TRANSPARENCY?? Wow that made my day...well... night (it's 2 AM :P)
-
Transparent walls?!
Oh my GOD!
This is ridiculous!
-
Transparent anything, or just walls? Having transparency is nice at any rate.
-
Transparency! Woah, this is incredible! I'm at a loss for words.
Wow. ;D
-
Transparent as in "holes in walls", not glass (glass would require drawing all the walls from farthest to closest).
EDIT: Blarg. The fact that my blocks each have four faces makes the fences look rather strange. It also makes the engine very slow, so never mind it :(
-
Oh... :( Now we're all disappointed. Well, holes are still somewhat useful...
-
Still, this is awesome. I'm excited to see what can be done. Keep it up bwang! ;D
-
Bwang, I figured it might effect the speed of the engine if you had to use overdraw (the only way I know of to make transparent wall textures) because of the need to continue looping after a wall intersection. But thanks for trying anyways, it's cool that you're listening to my suggestions, as off base as they might be sometimes.
-
aw too bad it won't work, still, nice work on this project so far, though.
-
Bwang, I figured it might effect the speed of the engine if you had to use overdraw (the only way I know of to make transparent wall textures) because of the need to continue looping after a wall intersection. But thanks for trying anyways, it's cool that you're listening to my suggestions, as off base as they might be sometimes.
I need to continue looping after a wall intersection anyway, because of the variable-height columns (so a slice of wall may be partially hidden). Right now the problem is if a cube has holes, the engine will try to draw all four faces of the block, which looks terrible. The only way I can think of to remedy this is to make the rendering unit a face of a cube instead of a whole cube, at the expense of making the level format harder to comprehend.
Does anyone have optimizations for the code? Or should I add more comments to make the source more readable?
I might try writing an external level loader next, so textures and maps would no longer be hard-coded.
-
I've decided to prepare a release for ticalc.org. I have two requests:
(1) Can someone make me an animated screenshot of the latest version for ticalc.org?
(2) Does anyone know where I can find the source of the BMPtoC.exe program in this (http://ti.bank.free.fr/index.php?mod=archives&ac=voir&id=1630) program? I would include a modified version of it in my package for texture creation, and/or use the source to write a texture loader.
-
I can do an animated screenshot, but it will be split in several screenshots. I think ticalc limits each files to 1 MB. An animated screenshot for such thing will hit 1 MB in about 10 seconds.
-
That's fine.
-
Do I need to wait for a new version btw? Or do I use latest one?
-
You can use this one.
-
Ok I'll try to do some screenshots as soon as possible.
They'll run at 10 fps
EDIT: Here are some. Pick your favorites. The two first run at 5 fps, though. The rest are all at 10
Btw you oughta include a readme in the next release with controls so people know what keys does what.
-
Nice! Thank you.
I'll put a Readme in the next release.
-
IN later releases, are you planning maybe to have some sort of example mini game, for example, just a small map where you need to find a gun, avoding enemy shots, then reach the end, killing the boss? Just something simple so people see what kind of games could be done
-
I might. Right now, I write some proper documentation, and maybe a simple guide on how to get started programming the Nspire.
-
It is so good to start seeing Nspire graphics.
Can you optimize the engine to get some more FPS? (without reducing resolution)
I think a FAT engine (see the FAT engine for 68k calcs, it is the engine that DOA uses) for Nspire will be a great project to open game oriented programming to it.
But from all doubts that bwang has about available C functions, Nspire is not yet an easy calculator to program.
-
I'm trying to optimize it right now. I think a good place to start would be trying to change some of the math to fixed-point.
The Nspire is not that hard to program right now. The graphics functions are quite usable, we have things like malloc(), and from what I've heard we also have file access functions. The only essential thing we don't have right now is text I/O. The fact that most of the standard library is missing doesn't really affect game programming.
-
Ok, good to know. But a library with several graphics functions (sprites, tiles mapper, custom font routine) and other functions could make easier for starting.
I will later get involved in Nspire scene after I am somewhat realized in z80.
-
Glad to see it's going on ticalc now ^^
-
Glad to see it's going on ticalc now ^^
Another nice program.
ticalc has been flood with good projects, I didn't saw nothing like this. And some for a long time. Omnimaga is start to make a huge impact in reviving releases activity into ticalc.
-
Yeah true. It seems a lot of major stuff comes from this forums. Back then it was TCPA, RadicalSoft then later Detacheds and Macross Software. Then it was MaxCoderz and then barely anything came out. Now it definitively seems calcs have done some sort of comeback
-
Ok, good to know. But a library with several graphics functions (sprites, tiles mapper, custom font routine) and other functions could make easier for starting.
I will later get involved in Nspire scene after I am somewhat realized in z80.
I've been thinking about writing a library. I have some useful functions used by the ray caster (draw to a buffer, sort an array, and some math functions) and I might split them off into the beginnings of a separate "Nspire Utility Library" project.
-
Congrats on the feature! You deserve it :)
-
Gasp! I'm featured!
-
Congrats indeed! I was wondering why you weren't featured already. Finally it turned out the staff were busy so they had like 4 or 5 features in their news queue, waiting to be posted one by one every few days. You deserve it.
/me hopes you will finish this project too and that someone makes a game ^^
-
Congrats on the feature Bwang! Definitely worthy of a feature! =D
-
Congratz on the feature! Even though I didn't try it out myself (I don't want to downgrade from 2.0.1), the screenshots are all epic! Awesome work!
-
Yeah, Silver, I know how you feel! I can't wait for ndless 2.0!
-
Are you still planning to make a small demo game using this engine or if development for this is completly over? (noticing the lack of updates in a long while, despite school being done)
-
It's not over yet! I have another Nspire project that I'm working on at the moment.
-
Aaaah ok, I'm glad it's not dead. I hope you announce your other project once it has enough progress ^^
-
Yeah, I'll probably return to this project some time to clean things up, convert everything to fixed-point, and make a real demo.
-
You should also make a "lite" version, aimed at doing more basic stuff, like a 3d maze, that only has fixed height walls, a single wall texture, etc. It would be easier to write programs with and run faster.
-
I should probably allow the client program to turn various features on and off.
-
One cool thing that could be written with this engine, assuming doors are supported, would be a RPG. It would be nice to see some sort of 3D-ish RPG using such engine, altough forests would probably look a bit weird if made of walls only.
-
you could always throw in some algorithms to test if a ray intersects a particular plane defined by 3 points within that triangular (or rectangular if 4 pts) boundary defined by those points. Then you have 3d models of whatever you want (within the computational feasibility of the nspire). Ex: a tall pyramid atop a tall rectangular prism for DJ's tree. :)
-
The problem there is that he is only casting a single Ray for every column, you would need to cast a Ray for every *pixel* for that to work.
-
Yes, that would be ray tracing. Real time ray tracing on an Nspire would be ridiculous.
-
Except I seem to remember you writing one ;)
-
That one, if I remember correctly, took a few seconds to draw the scene.
-
True. Also 3 PS3s together couldn't even get 3 fps on raytracing. Keep in mind it was on a much larger resolution, though, but it tells how much intensive raytracing is.
-
True. Also 3 PS3s together couldn't even get 3 fps on raytracing. Keep in mind it was on a much larger resolution, though, but it tells how much intensive raytracing is.
Really? I figure that would be more than enough power to get at least somewhat decent raytracing. If you saw this on a video, keep in mind that all PS3 homebrew doesn't take full advantage of what the PS3 can do, since Sony has hardware access restrictions.
-
Yeah I think it was homebrew, not sure anymore, though. It was in 2007 or something.
-
What is the format for the map? I want to make a 3d maze, so I need to know this for the generation algorithm.
-
A n x n map consists of 3 (n+2) x (n+2) arrays: int map, float height, and float alt. For all 3 arrays, array[0][k], array[n+1][k], array[k][0], and array[k][n+1] (the four edges of the array) are padded with 0's for internal reasons. map[p][q] contains the texture number + 1 of the block at (p, q) (so a block using texture 0 would have a 1 here). height[p][q] contains the height of the block at (i, j) (each block is 1x1xheight). alt[p][q] contains the altitude of the bottom of the block at (p, q). For a maze, height should be filled with 1's and alt should be filled with 0's.
-
Yeah I think it was homebrew, not sure anymore, though. It was in 2007 or something.
Yeah, he said in the beginning that using Linux(through OtherOS) he has access to 2 SPE's per console, when each one actually has a total of 7 SPE's, where only 2 are made available. I actually didn't think that such a severe limit was placed on them, I figured you had a at least half of the available accessible O_o
-
Well idk what that means x.x but I guess it sucks that such limit was added
-
I have two questions about the engine:
A. How does the engine react to non-square textures?
B. Is there a way to disable sprite drawing? (Having nothing in the sprite struct gives an error)
-
A. I'm not sure. Just scale them on the GIMP or something so that they are square.
B. Set numSprites to 0.
-
@fb39ca4: How's the maze going? Just wondering...
In case anyone else is wondering, this project is not dead. I'm moving off to college in a couple days, so things have been quite hectic, and I don't want to work on anything large for the next couple weeks. Maybe some smaller projects, but not the rather daunting task of converting the engine to fixed-point.
Speaking of which, does anyone know a systematic way to convert code to fixed point (integer arithmetic)?
-
Aaah I see. Good luck into moving to college. I hope you still have some free time to work on it on and off there :)
-
Yeah, I do hope I find coding time in college. Fortunately, the freshman year classes are all rather generic and fairly straightforward, and the homework seems pretty sparse (usually one problem set a week per class, and a problem set is only a few problems :))
-
@bwang: I finally got the map modification working, but now I have a bug in the maze generation algorithm that makes the maze unsolvable. Once that's fixed, I'll probably add a timer, then it should be done.
I hope you find some time to convert the engine to fixed point, then it would be powerful enough for a starfox-type game.
-
For those of you who have been looking at the Ndless SVN, a development build of Ndless 1.7 was made available to the public a few days ago. This new release re-structures the directories and makes it compatible with the new Ndless.
There are no code changes, however.
-
Why isn't this on the news?
-
Because Ndless 1.7 is currently unstable, and we do not want end-users to download it and experience crashes.
-
where is it? can I have a link?
-
It is in the Ndless SVN repository. You need to manually build it, and it is not compatible with the current release of gbc4nspire.
-
bah, what is a SVN repository?
-
Because Ndless 1.7 is currently unstable, and we do not want end-users to download it and experience crashes.
I was tempted to add it to the news but I was not sure yet. I prefered to keep it quiet until we are certain it works fine.
Does it means it works on OS 1.7 btw?
-
I think, (apcacl got it for me) I cant wait until there is a released one!
aw, the gbc emu wont work :(
-
Ah ok. Too bad about the emu, though. I hope calc84maniac eventually rewrites it for new Ndless versions.
-
Does it means it works on OS 1.7 btw?
Yep, actually, it does not even support OS 1.1. :)
Also, calc84 said that it *might* be possible to edit the current version to support this version of Ndless.
-
Wow awesome. Ndless for newer OSes is finally arriving!
Now to see how fast TI will remove OS 1.7 from their site. I wouldn't be surprised if OS 2.2 came out the day after Ndless 1.7 comes out, preventing downgrades to 1.7 too :P
-
hmm, I wonder how long until the stable version of 1.7 is out :P
Nah, I really need to keep my 1.7 OS hidden in my computer for later use XD
-
Now to see how fast TI will remove OS 1.7 from their site. I wouldn't be surprised if OS 2.2 came out the day after Ndless 1.7 comes out, preventing downgrades to 1.7 too :P
Don't worry: we are watching this closely.
And if it is the case, we're going to post everywhere as we've allready done with OS 2.1, so that nobody will install the 2.2 OS without knowing the consequences.
-
It really is a shame...come on, TI, just let us program in peace.
-
How about a computer program that converts the old into the new?
-
It is in the Ndless SVN repository. You need to manually build it, and it is not compatible with the current release of gbc4nspire.
Can this be fixed/patched easily ? . . .
-
Yeah good idea.
Also critor you could see the fuss OS 2.1 caused in the community. The post you made about it which was moved to news had close to 300 comments and even ticalc.org, which normally remains neutral, recommended people to not downgrade. Our duty now is to continue warning people of future traps set by TI, since a lot of new members join every week
TI won't get us!
-
I Agree!
now, which directory of the SVN is the beta of 1.7 at?
also, while we are opposing a 2.2, the tards at that google group are saying "YEAH! 2.2 WOULD BE AWESOMEZ!"
-
You have to download all of the files and build it yourself using the instructions in doc/Ndless-Development.txt (it might not be named exactly that, but it is close :P)
-
So there's no hope of converting gbc4nspire, because there's no source code anymore.
-
FALSE! :D Calc84 said on IRC that he could modify the binary.
-
Wasn't he planning to rewrite it eventually anyway? That said, if he can modify the binary it might be better I guess if it's not too hard
-
Yeah, I think he's re-writing it.
-
As this rewrite might take a while, it might be a good idea to update the old version so it will run on the new Ndless.
Edit: In case this wasn't clear, I meant gbc4nspire
-
As this rewrite might take a while, it might be a good idea to update the old version so it will run on the new Ndless.
Edit: In case this wasn't clear, I meant gbc4nspire
It is a good idea! :)
-
woot calc84
-
Could someone please compile Ndless 1.7 and email it to me?
-
I am with Silvershadow here
-
I'm not sure ExtendeD wants binaries of the program to be distributed. I'll ask him.
-
ALthough I am unsure between legit forum members. Maybe it is fine in that case, but again, we need to be careful to not make them too public or easy to use, otherwise if it's not very stable, some people could screw up their calc and have an hard time fixing them.
-
Maybe in the members-only section?
-
I would say not to distribute it.
It is fine to test it on the emulator, but I found some odd stuff it does to the Nspire in official Nspire documents, which I reported to ExtendeD, that would probably confuse many users (including myself).
-
I would say not to distribute it.
It is fine to test it on the emulator, but I found some odd stuff it does to the Nspire in official Nspire documents, which I reported to ExtendeD, that would probably confuse many users (including myself).
D: like what? I got installed (thanks to your ever-lasting patience) and the only bad thing was the number of attempts it took me (i just hope my connectors dont get lose)
-
Maybe in the members-only section?
You mean Randomness? One issue is that there are a lot of members, a lot of which are very new
-
Hey, where is the ndless svn? I didn't know there was one! :P
-
Hey, where is the ndless svn? I didn't know there was one! :P
Here -> https://www.unsads.com/scm/svn/nsptools/Ndless/trunk/
-
Information on the development version of Ndless is available here: http://www.unitedti.org/forum/index.php?showtopic=9284
-
hmm, I wonder how hard it will be for calc84 to update his emu
-
hmm, I wonder how hard it will be for calc84 to update his emu
Goplat has allready patched the binaries from calc84maniac's emu for Ndless1.7 compatibility.
http://ti.bank.free.fr/index.php?mod=archives&ac=voir&id=1953
-
O_O thanks!
anywho, I notice that ndless goes away because every so often, when you turn on and off, the calc reboots, getting rid of ndless
-
O_O thanks!
anywho, I notice that ndless goes away because every so often, when you turn on and off, the calc reboots, getting rid of ndless
I know.
You should increase the "hibernate" delay or even disable it, so that the calcultor won't reboot after being turned off.
-
Will batteries get drained like crazy over the days if hibernating is disabled completly, though? I myself have it set to 1 day.
-
O_O thanks!
anywho, I notice that ndless goes away because every so often, when you turn on and off, the calc reboots, getting rid of ndless
I know.
You should increase the "hibernate" delay or even disable it, so that the calcultor won't reboot after being turned off.
no, I mean if I just go "on" "off" "on" "off" "on" it will reboot within 5 mins
-
Will batteries get drained like crazy over the days if hibernating is disabled completly, though?
Yes!
You'll have to choose...
-
whoosp, check my post, I took it out of thew quote xx
-
hmm qazz42 I your quoting attempt messed up indeed x.x.
@Critor ok, I guess for now it might be best that I just avoid disabling it then x.x
-
ok, but seriously, I dont know why the nspire reboots after every 3 power-offs
wanna explain to me about that critor? and how to prevent it?
-
My Nspire never reboots after power-offs. Even with Ndless installed.
-
My Nspire never reboots after power-offs. Even with Ndless installed.
Neither does mine...
Ndless 1.7 is still unstable, you know.
-
weird, it always does this to me, even without ndless. I will turn on, then off then on then off then when I press on, it does a reboot instead of just turning on
perhaps this is for my nspire only.... 2.0 does not do this x.x
-
Weird. Could it be due to your issue with connectors being loose?
-
no, it happened scince I first got it, perhaps turning off hibernate will fix it?
edit: only happens on 1.7
-
It might help. Does the hibernation mode have an option to hibernate immediately after turning it off? I have mine set to 1 day of non-use but I forgot if there were faster hibernate mode triggering options
-
nah, mine is the same as yours, let me try something
edit: yep, I keep on getting reboots every 3 or 4th time I turn off and on
ExtendeD, if you can see this, can you consider making it so that ndless 1.7 wont go away with every reboot?
-
It's planned but not a priority.
Has anyone encountered the same reboot issue as qazz42?
-
One concern I have is that he mentionned a few times that he had the reboots even before installing Ndless 1.7. I hope his calc isn't damaged or something...
-
remember, this is on 1.7 only, so I really dont mind
on 2.0 there are no reboots
(wait, if you make it so that installing ndless does not involve connecting to a computer, that could also fix the problem, I mean, what If I have a reboot while there is no computer handy?) plus, if the install ation didnt fail 90% of the time, that would make the reboot problem feel like nothing
-
remember, this is on 1.7 only, so I really dont mind
on 2.0 there are no reboots
Out of curiosity, what is the date of production of your Nspire. (This can be found on the back next to the serial number, it reads P-<month><year>F.
-
errr, just curious, but why?
-
The Nspires made in 2007 were not affected by the Power Management Bug of OS 1.1. I was wondering if there was a possibility of a new "Power Management Bug" with another Nspire hardware change, this time with OS 1.7.
-
Darn... I hope the new Ndless won't cause more hardware issues and this time on new OSes x.x. It would suck if all OSes got affected. If that happens, couldn't it be something wrong with Ndless? I always wondered if that power management bug was fixable :/
-
Darn... I hope the new Ndless won't cause more hardware issues and this time on new OSes x.x. It would suck if all OSes got affected. If that happens, couldn't it be something wrong with Ndless? I always wondered if that power management bug was fixable :/
From what we can tell so far, Ndless is not responsible at all for these bugs, they happen even without Ndless installed.
-
Really? I might have forgotten/misunderstood then x.x
It sucks TI isn't even making sure all their Nspire hardwares are compatible with all Nspire OSes...
-
remember, this is on 1.7 only, so I really dont mind
on 2.0 there are no reboots
So you mean your calculator is unstable on OS 1.7 even without Ndless?
-
From what I could gather, this is what he means, as he mentionned having this issue even before he tried this version of Ndless.
-
well, I remember that when I used OS 1.6 and was in 84 mode, every 5th power-off or so would lead to a reboot
-
is anyone porting this to the cx?
-
What I wonder is... if nDoom runs this fast, could this Raycaster be done to run even faster?
-
Does the raycaster work on the nspire, or do you have to use nspire_emu? I am having alot of trouble with nspire_emu. I can't create the flash image. The command prompt says that the syntax of the command is incorrect.