Are you serious ? x)I started nGL some days before nCraft..
I started nAk3D two months ago with an openGL like api !
Yours is obviously finished. ^^
Whats strange, is that I started using fixed point numbers and had a headache when multiplying matrices (int overflows) and then went to floating point and didn't seemed to lost any performances.Weird. I'm using int_fast32_t as storage and the lowest 8 bits as fractional part. (~0.004 accuracy).
The only difference with nAk3D is that it uses nGC and an heap sort face algorithm instead or your zBuffer.Z-Buffer has some advantages: constant performance, overlapping triangles and you can maybe use the depth image for e.g. lighting.
What ? nCraft is by Chockosta ...Are you serious ? x)I started nGL some days before nCraft..
I started nAk3D two months ago with an openGL like api !
Yours is obviously finished. ^^
nGL doesn't have a function to define the viewport or the frustrum yet.I've seen http://www.scratchapixel.com/lessons/3d-advanced-lessons/perspective-and-orthographic-projection-matrix/opengl-perspective-projection-matrix/ a couple days ago that works well.
The accuracy of my fixed-point type is also too bad for most programs which use a 1 unit = 1 meter baseI experimented the same problem, too large numbers explodes integer capacity when matrices are involved.
And if I use Windows ? <_<Then use drapes.
So, I fixed a few bugs in nGL (fewer crashes) and converted my snake game (I made exactly one year ago) to 3D.
No special features, just plain snake.
You can still move around and look.
The apple is just a cube with apple texture (I found on the internet), I couldn't find a suitable 3D model of an apple and I can't use blender.
Every block on the screen is drawn and textured completely, the game isn't optimized at all (walls between two wall blocks) but still runs smooth.
Sorry, but I'm more programmer than game designer and I just couldn't do it any better...
Controls: 8-6-4-2: Move snake
WASD: Move around (for testing with nspire_emu)
touchpad: Look around
(http://www.omnimaga.org/index.php?action=dlattach;topic=17596.0;attach=16452;image)
It's a bit slower on calc than on the emulator, I suspect it's the touchpad polling every frame, but if that get's a real issue, I'll take care of that.I notived that on my nAk3d project (dropped down due to your way better GL implementation :D ).
If you want to use nGL, grab gl.cpp, gl.h, fastmath.h, fastmath.cpp, fix.h and don't forget to read gl.h and #define SAFE_MODE in gl.h!
I then managed to create a keypad pooling without using an interruption handler. It uses the ndless code of sleep.c that setup an arm co-processor to wakeup the arm processor when a certain time has arrived. This let me cleverly set my keypad pooling without spamming at each frame.Or I register a function as a keypad interrupt handler which sets some bits of keys currently pressed to 1.
Now that I think about it, 3D snake would be too easy.Depends. At first yeah, you are doing it on purpose if you hit something. But when you start being long, you don't see where your tail is when it is not on the face your head is on ;)
UPDATE! ;D
I made some progress on nGL and made another demo (which is again, not intended to be "played"): crafti!
Changes:
- Faster! A lot faster, actually. I can't tell any numbers, but with large triangles it went from slow to smooth :hyper:
- Interpolating colors between vertices, which is actually slower than textured rendering
- Prefixed functions with ngl (for example nglInit)
- Something like vertex arrays (nglAddVertices)
- Wireframed rendering
- Doesn't crash anymore
- Some documentation
- Clipping! (X: Per pixel Y: Per line Z: Per triangle)
Todo:
- Colored textures (non-interpolated)
- Compressed textures (zlib). nGL doesn't lose performance with higher-resolution images, they just get too big in raw format
- Make a real, playable, good looking game which uses nGL
- FPS counter
It looks a lot better on the emulator and on calc than these gifs (byzanz-record is crap):
(http://img.ourl.ca/crafti_colors.gif)
(The emulator runs at 90% speed here, I accidentially hit F9)
(http://img.ourl.ca/crafti_textures.gif)
The textures used aren't mine this time, terrain.png came from http://www.planetminecraft.com/texture_pack/fancycraft-by-jjjas0n-64x64-version-100.
Also, the controls (same as nGL in the first post) are a bit weird to use on a PC so the twitches you see are just my fingers finding the keys.
It's a bit slower on calc than on the emulator, I suspect it's the touchpad polling every frame, but if that get's a real issue, I'll take care of that.
If you want to use nGL, grab gl.cpp, gl.h, fastmath.h, fastmath.cpp, fix.h and don't forget to read gl.h and #define SAFE_MODE in gl.h!
Do you think this engine would be powerful enough for a Minecraft game? Chockosta made one in Lua with no textures but it ran at 10 FPS at 230 MHz, even if it only rendered stuff within a three tiles radius."crafti" runs at > 20 fps with textures and ~50 without, so it should be possible to play with.
Wow, a Minecraft clone using this engine would rule! How does it handle a 512x512x64 map?Not at all, I tried it. 16*16 chunks of 16*16*16 blocks = 1 FPS...
I'm using fixed-point (1/256 accuracy) so it could be.How do you render them? If you render every block individually, you waste a lot of time drawing invisible parts. Even a computer can't handle this. You need to generate meshes which contain only the sides of the block that are exposed to air (or to any non-solid block if you include any). Then you should notice a huge performance increase. (The real minecraft does this)
But I assume the things you saw were caused by a mixture of my .gif recorder and normal aliasing.
Edit:QuoteWow, a Minecraft clone using this engine would rule! How does it handle a 512x512x64 map?Not at all, I tried it. 16*16 chunks of 16*16*16 blocks = 1 FPS...
4*4 chunks is the maximum usable size (~8fps), too many triangles
glBegin(GL_QUADS);
nglAddVertices(buffer, buffer_length);
glEnd();
To generate the VERTEX array, I simply iterate through all AIR blocks and render the corresponding sides of adjacent blocks.Aw too bad it runs much slower with 16x16x16. Does it mean a Minecraft clone using this would actually be slower than nCraft?I don't know the visible range of nCraft, but if it's < 32, crafti is as fast with textures as nCraft is without.
Does this require a specific (as in "not too old") revision of Ndless ? Because I can run nCraft but not crafti ("not supported").crafti uses c++ which supposedly needs bFLT to work correctly...
And yeah, I have a really old revision
edit Indeed, works with r914.
However, I only figured out part of the controls, and my calc froze at some pointAre you sure it froze and didn't just display the sky? I haven't had a freeze in a while, only crashes until I (hopefully) fixed them :)
The D-Pad and the number keys stopped responding. It's possible I made it crash myself though because I tried all the keys.QuoteHowever, I only figured out part of the controls, and my calc froze at some pointAre you sure it froze and didn't just display the sky? I haven't had a freeze in a while, only crashes until I (hopefully) fixed them :)
I tried to fix the depth issues and had to use floats (or int_fast64_t which is equally slow to divide somehow) which is slower (depends on vertex count)I'd say go for the fastest. It' only disturbing when blocks are really far.
Which version is better? Or should I keep both?
(http://img.ourl.ca/crafti_better.gif) (http://img.ourl.ca/crafti_worse.gif)
You are using fixed-points, right? Well, then you can kinda cheat a bit by setting the coordinates to e.g. 0.1 and 15.9 instead of 0 and 16. It's just as fast as the previous code, but after experimenting a bit with the values, you can get rid of the lines witouth visuall distorting the texture.I'm doing that already. I have a nice SAFE_MODE #define which tells me if something is read out-of-bounds and it was triggered with OpenGL like texture coords (0 - 1 on the edges) vs. nGL coords (0-1 - 1px on the edge pixels). As the lines are a unique color (for each texture) I don't think it's some out-of-bounds read (texture atlas, see below).
Since these textures are repeated, it would actually make more sense to wrap the texture coordinates. It would have to be tested per-pixel, however it should be fairly fast (as long as textures are a power of two size), just a bitwise AND on each coordinate value. For a minecraft engine, this would also open up the ability to simplify meshes in large, flat areas of the same block.The problem here is that I'm using a texture atlas.
I'd say go for the fastest. It' only disturbing when blocks are really far.Actually, with the improved indexed-rendering I'd have to do less floating-point calculations so it's not that slow.
I'd say that you should include both mode (with and without textures) in the final version so that we can make beautiful screenshots with textures and build quickly tooThat'd mean switching without recompiling, the problem here is that I enable and disable textures by #define ing TEXTURE_SUPPORT
(not that it is slow with textures, but it is faster without so if we want to make quick changes, we might want a quick way).
Why not do it like array textures in OpenGL?QuoteSince these textures are repeated, it would actually make more sense to wrap the texture coordinates. It would have to be tested per-pixel, however it should be fairly fast (as long as textures are a power of two size), just a bitwise AND on each coordinate value. For a minecraft engine, this would also open up the ability to simplify meshes in large, flat areas of the same block.The problem here is that I'm using a texture atlas.
As I preprocess every Chunk and basically just have to iterate over a array of vertices, I'd have to determine which texture to bind for every triangle.
That'd be horribly slow.
The problem is rather a rounding issue, as with fixed-point x / y = z can be true, but z * y = x doesn't have to be.
Or maybe I'm just completely wrong. Who knows. I'll have to fix those bugs anyway...
It avoids all the problems of texture atlasesWhich problems? Without texture atlasses I would have the same problems as I have no.
You bind to one texture, and then because the format and size of the different textures in the array are the same, you only need to select the appropriate location for the texture data, which can be done by storing an integer ID with every triangle.That's the problem. I'd have to switch the texture (even if it's just a id or pointer) every triangle and ALSO have UV-coordinates.
All the pixels from one texture will be together, increasing cache coherency as well.What about texture atlasses?
The problem with the texture atlases is that you can't wrap the coordinates, which will eliminate all the out-of-texture-bounds artifacts you are gettingNo, it won't. It would just look different!
Consider the following atlas:Could work, but wouldn't make a huge difference. 2*16*16 = 512 Byte, no problem for the cache to store multiple textures.
AABB
AABB
CCDD
CCDD
It would get stored as AABBAABBCCDDCCDD. An array would get stored AAAABBBBCCCCDDDD - all the information for each individual texture is together in memory.
Another thing that might help is to set GCC to the highest optimization level if you haven't already.My flags: -O3 -Wall -W -marm -ffast-math -mcpu=arm926ej-s -fno-math-errno -fno-tree-vectorize -fomit-frame-pointer -fno-exceptions
It's weekend again, so some more progress:Woah, if you or someone else can pull off a Minecraft game running this fast, this will be an HUGE milestone for the TI-Nspire and I bet this would be quite popular too. I am particularly amazed at how fast it runs even with textures and such viewing distances. The non-textured version with short view distance still looks very nice too, though. O.O
- Replaced terrain.png with original terrain.png from Minecraft (Copyright Mojang AB)
- Trees
- Infinite world generation (The trees are the only thing changing for now)
- Faster startup (cos uses sin_lut)
- Faster
With textures it's smooth now also with some more blocks visible (~25 fps):
(http://i.imgur.com/RX4HMdy.gif)
I had to use imgur for that one as I couldn't upload it to img.ourl.ca.
The file was probably too large and every file I try to upload now (name doesn't matter)
doesn't get uploaded and it shows "crafti_world.gif" (the old file name!) was uploaded successfully and a 404 NOT FOUND next to it...
Without textures we can expand the viewable distance a bit further and we get to ~11 fps:
(http://img.ourl.ca/crafti_world2.gif)
But for comparision fps-wise with the same distance as with textures above (~40 fps):
(http://img.ourl.ca/crafti_world3.gif)
Known bugs:
-Weird lines if textures enabled
-Sometimes a triangle hitting the right screen border shows random data if textures enabled
-Sometimes it displays garbage if perfectly aligned to Z axis
Is this demo optimized for cubesKind-of. I generate a list of Positions (x,y,z) and a list of IndexedVertices (a reference to a position, a color and uv-coordinates).
will it run as fast when it's smooth terrain with the same amount of vertices?It depends on how much triangles are visible. The "benchmarks" I performed earlier in this thread were totally wrong as my line drawing is slooooowwww.
for(int x = x1; x <= x2; x += 1, ++z_buf, ++screen_buf)
{
if(__builtin_expect(*z_buf > z, true))
{
*z_buf = z;
#ifdef TEXTURE_SUPPORT
*screen_buf = texture->bitmap[u.floor() + v.floor()*texture->width];
#else
*screen_buf = low->c;
#endif
}
#ifdef TEXTURE_SUPPORT
u += du;
v += dv;
#endif
z += dz;
}
What are your settings for nover to play this?
The use of the touchpad like a mouse is really a great idea!
The problem of the splitting into 16x16x16 pixels is that the variation of the length of view can have a factor of 2... Why not split into 8x8x8?
I can't wait to be able to save! :p
The file association works! Could you add a loading bar when we quit the program when it saves the world?The next thing I do will be a nice menu. A "saving bar" is unnecessary in my opinion (and difficult to implement as loading/saving isn't async).
Now, if I could suggest something: make the different same nature blocks distinguishable.How? Exactly how I did it when textures are disabled? (color *= 0.8f)
A "saving bar" is unnecessary in my opinion (and difficult to implement as loading/saving isn't async).It enables the user to know that it is normal that nothing happens and to know how much times he has to wait. If it is difficult to know the time needed to save, you could just display on the screen "saving...".
How? Exactly how I did it when textures are disabled? (color *= 0.8f)Not like when textures were disabled but put a different luminosity for each side (the same for all tops, the same for all east-oriented faces etc.). But yes for color*=0.8f. Since the loading time is currently really short, I think the better solution is the precalculation.
Or two different texture packs?
Both versions would increase loading time (before you can see anything) as I either have to precalculate the textures or load another one.
Or should I seperate textures from the main executable which also makes "texture packs" possible?
It doesn't take a noticable amount of time to load and save. The delay you experienced was the call to refresh_osscr() which isn't really necessary, so I removed it.A "saving bar" is unnecessary in my opinion (and difficult to implement as loading/saving isn't async).It enables the user to know that it is normal that nothing happens and to know how much times he has to wait. If it is difficult to know the time needed to save, you could just display on the screen "saving...".
But that would mean on a "wall"-like structure you couldn't see where you put a block. Checkerboard ((x + y + z) % 2 == 0) would make more sense, I think.QuoteHow? Exactly how I did it when textures are disabled? (color *= 0.8f)Not like when textures were disabled but put a different luminosity for each side (the same for all tops, the same for all east-oriented faces etc.). But yes for color*=0.8f. Since the loading time is currently really short, I think the better solution is the precalculation.
Or two different texture packs?
Both versions would increase loading time (before you can see anything) as I either have to precalculate the textures or load another one.
Or should I seperate textures from the main executable which also makes "texture packs" possible?
Is there no .tns in the .tar.gz file? I can't seem to find it.It is in there, somewhere.
Yeah I just tried it and it's amazing. For some reasons, though, the speed on my calc is pretty much worse than in nCraft, although it's still much better considering there are textures and much deeper field of view. I am wondering if it could be because I am running an older hardware (revision B or C I think) or due to outdated Ndless version? I generally get between 2 and 8 FPS depending of how many blocks there are on the screen. My calc's AHB is setup to 66 MHz btw.That shouldn't be the case, it runs much faster than nCraft (though slower than nspire_emu, which says 16-18) on my calc (~10fps, never below 5)
I like the new grass blocks! Great work!I know I'm good at stealing minecraft's terrain.png.. But I'll have to change that sooner or later..
You should maybe use a height of only 20 blocks because the world generation is really really slow.I know, but the height doesn't matter that much. It's more the smaller chunk size.
Suggestion: not need to jump to climb on a simple block. It would enable to climb stairs without jumping.I find jumping better than just "glitching" on top of a block.
The world generated may be too embossed.The generator has a maximum height of 0.7 times the world height.
can you use blocks like a crafting table or furnace yet??No, what should they do? There is no inventory or items at all and all available blocks are accessible through "."
(can't find the button to remove my post -.-)Which post? I can't find the button on my posts earlier. I could swear it was there earlier this day...
@DJ_O I had that glitch too, but it got fixed by making the field of vision a bit longer by pressing +. I think what's happening is you're jumping into a place before the calc has loaded it.If you have any issues please let me know! Otherwise I may think it's not as important or it doesn't happen often.
Also do you think, grass, water and lava (including their flow/physics) would be hard to implement?Grass flow? Do you mean grass spreading onto nearby dirt blocks?
Really, REALLY cool!Thanks!
Could there be a readme file though please?What should be in there? Instructions, controls, changelog, license?
Nice job!Somehow the bug resolved itself with the last change to the libstdc++ compile flags (I think -fpic)
Did you ever get elf2flt to speed up when linking against libstdc++? When I tried last time, it took forever and froze my computer.
Also: in the README, it says you're using something called PerlinNoise, which is licensed under the GPL. So shouldn't the whole program be GPL'd to comply with the license?It's basically CC-NC-SA except for the PerlinNoise class and the texture. The texture didn't contain a license so I didn't care.
The texture shouldn't matter because it's just data.So if anyone draws anything and publishes it, it's just data?
THat would be nice, although just at least having grass at all would already be cool as well (since now it's pretty much desertic lol)QuoteAlso do you think, grass, water and lava (including their flow/physics) would be hard to implement?Grass flow? Do you mean grass spreading onto nearby dirt blocks?
? I added grass blocks in 0.7 IIRC.THat would be nice, although just at least having grass at all would already be cool as well (since now it's pretty much desertic lol)QuoteAlso do you think, grass, water and lava (including their flow/physics) would be hard to implement?Grass flow? Do you mean grass spreading onto nearby dirt blocks?
What should I implement next?A readme ? :P
I didn't follow development but the fact that you pulled off a textured voxel engine (even though without lighting) at a pretty decent speed is quite impressive.I find lighting rather annoying. And what's the difference between a "voxel engine" and 3D triangles? AFAIK a voxel engine is optimized for different sizes of voxels and has a better storage and rendering algorithm (most of the time with octrees).
That looks really awesome! This is the first time I tried it on a real calc, and the speed is really decent.I didn't want to make a second "Saving" image.. But I'll fix that when fonts are working!
I think it's a little weird that it says "loading" when exiting, though.
Indeed. When I tried the program I had to search through a dozen of pages of replies just to find the controls and I still felt I missed some.
A readme ?Umm, README.md has been there since v0.7.2.
Maybe even an ingame readme in case people forgot which was the key to do some specific action
Well I thought voxel engine = cube tilemap renderer but w/e. :PQuoteI didn't follow development but the fact that you pulled off a textured voxel engine (even though without lighting) at a pretty decent speed is quite impressive.I find lighting rather annoying. And what's the difference between a "voxel engine" and 3D triangles? AFAIK a voxel engine is optimized for different sizes of voxels and has a better storage and rendering algorithm (most of the time with octrees).
New feature release: v0.8!
New features:
- Crafti now uses block data (8 bits per block), which means your save files won't be compatible
- Torches in all directions (even upside-down)!
- Flowers!
- Mushrooms!
- Spider webs!
- Cake!
- Faster chunk culling!
- Ability to load external textures ("/documents/ndless/crafti.ppm.tns") in PPM format (24bit binary)
- A splash screen (From the internet, I only added the text "crafti")!
- Message "Loading" now shown when crafti is doing some heavy processing
- Disabled the mode with textures disabled, it was too ugly and slowed down the startup somewhat
Bugs fixed:
- Clock on screen
Known issues:
- With HD textures the block selection menu becomes unusable (but 1 and 3 still work)
- Front side of blocks is fixed (all furnaces face the XY-Plane)
- CLIP_PLANE too close
- Can rotate more than 90° horizontally, which turns the screen upside-down
(I'll probably fix all of them in v0.8.1, but that'll likely take a while)
Screenshots (BTW, hd textures don't make the game slower ;) ):
(http://img.ourl.ca/crafti_splash.png) (http://img.ourl.ca/crafti_hd_good.png)
(http://img.ourl.ca/crafti_torches.png) (http://img.ourl.ca/crafti_block_list_v0.8.png)
What should I implement next?
And BTW, I'd be very glad if anyone could design a better menu or "Loading" message for me, I suck at art ;D
My goodness, that looks fantastic!Thanks :)
For fonts, you can use nGC or Freetype (which works without any changes)Does nGC support rendering into (raw) buffers with different width than the screen?
Bug Report: when I try running crafti, my nspire crashes and burns.Do you need a fire extinguisher? You'd have to pay the shipping cost, though :P
I don't remember the details about freetype, but I can give you a sample program. It is fast, and not that big.Hm, could you compile freetype into a static lib and make a pull request on github.com/OlivierA/Ndless? I'm sure it'll be useful. You should also include the sample.
Writing a custom font rendering routine is easy, I only need two different font sizes, and I need real performance.Well it depends whether you use a vector or bitmap font anyway. ;) Of course the latter is faster but the former scales better. Also with bitmap fonts you'll most likely have to scale down, which is much slower than scaling up. So maybe there isn't that much of a difference.
nGC uses the OS' font routines AFAIK which are slow and ugly, Freetype is probably slow as it's using splines, bezier-curves and such things..
QuoteI don't remember the details about freetype, but I can give you a sample program. It is fast, and not that big.Hm, could you compile freetype into a static lib and make a pull request on github.com/OlivierA/Ndless? I'm sure it'll be useful. You should also include the sample.
Also for the bugs, is it just me or do textures right up against the player seem really weird, especially underground?Jup, for speed purposes I ignore the depth for texture mapping.
Wait, mobs are possible ?Compared to the rest they consist of a fairly small amount of triangles!
Why no crafting though ? Maybe it could be implemented similar to what Jens K did with MC2D ?Crafting means recipes, items, more GUIs, a cursor etc.
Ugh, I dislike it when I vote, then see the results and I'm the only one who voted that.Same, I voted for ********.
I voted for the inventory because I thought it would not take ages to code (unlike mobs, water and lava or redstone)After the necessary refactoring, water, lava and redstone should be very easy. Inventory would mean creating more textures and a whole new API.
I won't publish v0.8.1 yet, as I still have to implent rotation of normal blocks, which requires refactoring a lot.So, upside-down stairs? :)
Maybe. Stairs aren't implemented yet, but that shouldn't be much work. I was referring to furnaces, crafting tables, bookshelves and pumpkins, actually. Stairs are "special blocks" as they don't consist of 6 axis-aligned quads with coords aligned to BLOCK_SIZE which is necessary for optimizations.I won't publish v0.8.1 yet, as I still have to implent rotation of normal blocks, which requires refactoring a lot.So, upside-down stairs? :)
Wait...what do you mean by rotation then? Will the firery side of the furnace face you when you place, or is it something different?Maybe. Stairs aren't implemented yet, but that shouldn't be much work. I was referring to furnaces, crafting tables, bookshelves and pumpkins, actually. Stairs are "special blocks" as they don't consist of 6 axis-aligned quads with coords aligned to BLOCK_SIZE which is necessary for optimizations.I won't publish v0.8.1 yet, as I still have to implent rotation of normal blocks, which requires refactoring a lot.So, upside-down stairs? :)
Exactly that! The torches do that already (dependent on the side of the block you place it on).Wait...what do you mean by rotation then? Will the firery side of the furnace face you when you place, or is it something different?Maybe. Stairs aren't implemented yet, but that shouldn't be much work. I was referring to furnaces, crafting tables, bookshelves and pumpkins, actually. Stairs are "special blocks" as they don't consist of 6 axis-aligned quads with coords aligned to BLOCK_SIZE which is necessary for optimizations.I won't publish v0.8.1 yet, as I still have to implent rotation of normal blocks, which requires refactoring a lot.So, upside-down stairs? :)
for(int x = x_start; x <= x_end; ++x)
{
COLOR c = texture->bitmap[u + v*texture->width];
RGB rgb = fromCOLOR(c);
r *= light;
g *= light;
b *= light;
c = fromRGB(rgb);
screen[x + y*width] = c;
}
For each horizontal line of every triangle visible. Maybe it's possible to premultiply the textures, but for 4 different levels of light that's already 2MB for a 512px texture. I don't know, maybe in a later version.
Maybe it's possible to premultiply the textures, but for 4 different levels of light that's already 2MB for a 512px texture. I don't know, maybe in a later version.
I was going to suggest exactly this. Keep in mind that (I believe) a lot of people are happy with the original 16px textures, and with those you could have copies of one texture for all 16 light levels in only 8KB. Of course, if you implemented this for all block types it would start to add up, but it would still only be about 2MB for basically every block in current Minecraft, which includes far more block textures than you'd need with the current set of blocks supported.Considering that the CX has 64MB RAM and the OS runs on older models with 32MB, there's at least 32MB free (maybe badly fragmented), so that could actually work quite well (but slow down startup time significantly). I added it in the poll above.
Also, hi. :P I normally don't tread outside of 83+/84+ threads, but this is the one thread that I make an exception for and keep track of because your work on this is awesome.Thanks, what an houor :D
Out of curiosity because I don't have an Nspire and couldn't see the statistics anywhere in recent posts, what's the performance of this like relative to the draw distance?
If you mean draw distance as in how many chunks far you can see, then I'd say it's about 15fps with 3 chunks (or however many blocks are in one +/1) rendering distance(overclocked to 198MHz).That entirely depends on how many triangles are visible. If you have a flat area, it's not much slower, but with hills it slows down quite a lot.
(http://img.ourl.ca/crafti_2_28fps_normal.png) | Normal distance, 28 fps | (http://img.ourl.ca/crafti_2_22fps_normal%2B1.png) | Normal + 1, 22 fps |
(http://img.ourl.ca/crafti_2_17fps_normal%2B2.png) | Normal + 2, 17 fps | (http://img.ourl.ca/crafti_2_10fps_normal%2B5.png) | Normal + 5, 10 fps |
(http://img.ourl.ca/crafti_2_36fps_normal-1.png) | Normal - 1, 36 fps | (http://img.ourl.ca/crafti_2_57fps_normal-2.png) | Normal - 2, 57 fps |
(http://img.ourl.ca/crafti_2_41fps_up%2B5.png) | Looking up at Normal + 5, 41 fps |
QuoteI was going to suggest exactly this. Keep in mind that (I believe) a lot of people are happy with the original 16px textures, and with those you could have copies of one texture for all 16 light levels in only 8KB. Of course, if you implemented this for all block types it would start to add up, but it would still only be about 2MB for basically every block in current Minecraft, which includes far more block textures than you'd need with the current set of blocks supported.Considering that the CX has 64MB RAM and the OS runs on older models with 32MB, there's at least 32MB free (maybe badly fragmented), so that could actually work quite well (but slow down startup time significantly). I added it in the poll above.
Should we perhaps reset the poll, now that a new option has been added?No, my intention is to remove an option from the poll after I implemented it and add considerable suggestions and possible features on-the-fly.
Sorry for the delay, but here (https://github.com/OlivierA/Ndless/pull/4)'s the pull request. You can look at freetype_demo (https://github.com/Legimet/Ndless/tree/master/Ndless-SDK/_samples/freetype) in the samples directory.Looks good so far, but freetype seems to be a really big chunk of code with a complex API. Nevertheless I'll try it, once my fork gets up-to-date with upstream. Merging both can take a while, there are still two major issues (ndless_resources crashes and ndless_installer as well D: ).
I updated to GCC 4.9.0 by the way and the problem with elf2flt sucking all RAM out (if iostream is used) is there again :(
What? I only copied the headers, static library, and a Makefile to build it (and similarly for zlib).Oops, I didn't look at the content, just the amount of lines (>20.000) :/
git submodules sounds like a good idea, since we won't have to have prebuilt stuff in the repo, and we can build the libs from source.Yeah, compling nSDL, nspireio and the other two shouldn't take long.
It definitely is. WithI updated to GCC 4.9.0 by the way and the problem with elf2flt sucking all RAM out (if iostream is used) is there again :(
What do you think about making our own tool to convert elf to bflt? I think everyone agrees by now that elff2flt is an unmaintained piece of crap.
As for using freetype in crafti, just choose whatever works best. If you think FreeType is a good choice, just take a look at the sample, and put whatever font you use in a header file using "xxd -i" so people don't have to copy an extra file.I'll try some solutions. I'll probably end up rendering a font table with freetype into a buffer and use it to directly blit to the screen buffer.
Is this being compiled on a linux machine?Yeah, I'm not using windows, even if I wanted to, I couldn't. I haven't got a license key anymore, let alone free space on my drive.
QuoteShould we perhaps reset the poll, now that a new option has been added?No, my intention is to remove an option from the poll after I implemented it and add considerable suggestions and possible features on-the-fly.
It shouldn't make a huge difference anyway, as lighting doesn't have an impact on gameplay at all (yet).
QuoteFor fonts, you can use nGC or Freetype (which works without any changes)Does nGC support rendering into (raw) buffers with different width than the screen?
static char* screen_buffer[SCREEN_BYTES];
void draw()
{
ngl(screen_buffer, scene);
gui_gc_blit_buffer(gc, screen_buffer); /* syscall */
gui_gc_drawString(gc, "H\0e\0l\0l\0o\0 \0W\0o\0r\0l\0d\0\0", 0, 10);
gui_gc_blit_to_screen(gc); /* part of libndls */
}
static Gc text_gc;
void init()
{
text_gc = gui_gc_copy(gc, 100, 100)
gui_gc_setColorRGB(255, 255, 255);
gui_gc_fillRect(0, 0, 100, 100);
gui_gc_setColorRGB(0, 0, 0);
gui_gc_drawString(text_gc, "H\0e\0l\0l\0o\0 \0W\0o\0r\0l\0d\0\0", 0, 10);
}
void draw()
{
ngl(scene);
gui_gc_blit_to_screen_region(text_gc, 0, 0, 100, 100); /* You can even redefine this function in order to handle alpha */
}
nGC uses the OS' font routines AFAIK which are slow and uglySlow because of syscalls, and in my second example the draw method doesn't use any syscall on time critical code.
I also hit a bug in GCC 4.9.0, but it should be faster now, as one of the major features in 4.9.0 is a optimized LTO.What bug? I'm intrigued.
A segmentation fault: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61008 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61008)I also hit a bug in GCC 4.9.0, but it should be faster now, as one of the major features in 4.9.0 is a optimized LTO.What bug? I'm intrigued.
I have voted for water and lava :DWell, with 7 votes this is probably going to be it. v0.9 will take a while, though. I want to fix most of the graphical glitches and add some more "stuff" I don't know yet.
I also hit a bug in GCC 4.9.0, but it should be faster now, as one of the major features in 4.9.0 is a optimized LTO.
I actually thought about that, but it doesn't make much sense IMHO. One hand for rotation and the other for movement.Well on PC, you have one hand on keys and the other one on the mouse.
That's how GNU version numbering works. :P Major.minor.patch = overhaul.features.hotfix.I also hit a bug in GCC 4.9.0, but it should be faster now, as one of the major features in 4.9.0 is a optimized LTO.
Once Lionel Debroux said that GCC versions x.y.0 are buggy, and when 4.8.0 was the latest GCC, I ran into a bug that gave an ICE when compiling Ndless :P
I reported the bug, and it was fixed in 4.8.1.
So epic I hope you'll be able to port it to monochrome Nspires as well, or let someone do it for you (yes this is a proposal)nGL is open source, so of course everybody can - if that "everybody" wants to.
Other dimensions
LOL even though that would be awesome, in this case it's about the Nether and the End. :PQuoteOther dimensions
[/size]4D Minecraft? *.*
I hope the blur isn't too bad; I tried nDoom on a friend's non-CX calc and it was really hard to tell what was happening.Yeah I had this problem, although for me nDoom ran slightly slower than other platforms on the clickpad so that kinda solved my blurring issue. gbc4nspire, on the other hand, was completely unplayable with some games. Blame TI :P
LOOP
Calculate a batch of things
Draw
Key update (the order of the actions doen't mind)
ENDLOOP
for the batch calculations, you could track the index or the loop counter.
Just a quick question: How much could I increase startup time?
In v1.0 I'll implement some more optimizations, but it'll result in a slower start.
Wow ! Those are good improvements! :oThat's a bug I found yesterday by accident and I already fixed it ;) (Water was spreading to blocks even if there's already water)
Nonetheless, the game... laggs. Why does it lagg more with water and lava?
Feature requests:I can insert a if(keyPressed(KEY_NSPIRE_ESC)) somewhere in the middle of the splash screen, that shouldn't be too bad.
- Be able to open the menu or quit the game even when there is the "loading" label.
Ok, will do.
- Move on the items selector menu with the touchpad.
I think the priority is the speed up all the "loading" during the game.That's terrain generation and it will probably not get much faster.. :( Unless I can find a better way to generate terrain.
I hope I don't reach 40 seconds, but it's likely the framerate will increase by ~20-100% in some cases!QuoteJust a quick question: How much could I increase startup time?
In v1.0 I'll implement some more optimizations, but it'll result in a slower start.
I think the speed during the game is much more important than the startup time. I think you can grow it up to 40 seconds (currently 22 seconds) if you add a loading bar.
Thanks for your work! Do you mind if I upload it on tiplanet?Not at all, if you put a link to the github release page or this thread, just so that everybody can find the latest release and source code.
Wait, that means that if I stay on a "region" where everything is already generated, I don't have that loading anymore ?I think the priority is the speed up all the "loading" during the game.That's terrain generation and it will probably not get much faster.. :( Unless I can find a better way to generate terrain.
That's already implemented: Just increase the view range, wait until it's generated and decrease it again.Wait, that means that if I stay on a "region" where everything is already generated, I don't have that loading anymore ?I think the priority is the speed up all the "loading" during the game.That's terrain generation and it will probably not get much faster.. :( Unless I can find a better way to generate terrain.
Maybe you could add an option or something to waste 1 minute of time generating a "huge" map to save time later by not generating anything anymore ?
So are these worlds now infinite?No, not infinite, just 69905 blocks in X, Y, and Z-direction ;)
There also seems to be an xray bug where if you're underground, you can walk up to a block and see all through itI know, but I can't seem to find it :mad:
...So are these worlds now infinite?No, not infinite, just 69905 blocks in X, Y, and Z-direction ;)
But there will be more and more glitches and artifacts the further you go.
I downloaded the grayscale version and put it on my Nspire CAS (grayscale) touchpad. I get the splashscreen, then the UI for half a second, then it exits. It is in the root directory. I am using Ndless 3.6Do you have a touchpad or not?
Do you know why this is happening? If so, what's the fix?
That version just crashed on startup. Sorry D:Could you try it again? Maybe there wasn't enough RAM available.
I think it may be Ndless 3.6/OS 3.6 that is the problem, since Matref had no issues, and he has OS 3.1/Ndless 3.1That may be, but it works on CX CAS 3.6 (emulated) and CAS 3.1 (emulated clickpad) without any issues ???
Just un point: why does the "fast mode" seem to be slower on my calc?Weird. For me it's almost a 100% improvement.. It can't be slower, though. Maybe you accidentially changed the max. distance?
By the way, would it be possible to make the "loading" vanish while playing even though it reduces the speed? The loads would be progressive instead of all in the same time.Not really. I could generate 10MB of Chunks and use that, but it'd take 10 minutes to generate and also 10 minutes to load each time you want to play.
Weird. For me it's almost a 100% improvement.. It can't be slower, though. Maybe you accidentially changed the max. distance?Actually, the "fast mode" is faster but involves much more "loading"...
Not really. I could generate 10MB of Chunks and use that, but it'd take 10 minutes to generate and also 10 minutes to load each time you want to play.I was asking if instead of loading a block of map each time you need it, you could begin to load it progressively when we come close to it. This progressive load would reduce a bit the speed but would make the "loading" disappear.
And I'm not sure what you mean by "even though it reduces the speed".
That's just because of the higher FPS you also walk faster to the next unloaded chunks. You could turn the speed to "slow", I guess.Weird. For me it's almost a 100% improvement.. It can't be slower, though. Maybe you accidentially changed the max. distance?Actually, the "fast mode" is faster but involves much more "loading"...
That's basically how it works now...Not really. I could generate 10MB of Chunks and use that, but it'd take 10 minutes to generate and also 10 minutes to load each time you want to play.I was asking if instead of loading a block of map each time you need it, you could begin to load it progressively when we come close to it. This progressive load would reduce a bit the speed but would make the "loading" disappear.
And I'm not sure what you mean by "even though it reduces the speed".
That's just because of the higher FPS you also walk faster to the next unloaded chunks. You could turn the speed to "slow", I guess.Ah ok, you could be right. ;D
That's basically how it works now...But... didn't you speak about "the next unloaded chunk"? I meant not to load chunk by chunk but progressively. Doen't the "waiting" mean the loading of an entire chunk which hasn't been loaded at all yet?
Why, then, does it have to load all the generated chunks at start? Can't you just load selective parts of the file into memory, accessing like an array? (Guessing you don't have arbitrarily large block data yet, but you could still stick that at the end (found by a position dictated in the header of the save).)That's basically how it works now...Not really. I could generate 10MB of Chunks and use that, but it'd take 10 minutes to generate and also 10 minutes to load each time you want to play.I was asking if instead of loading a block of map each time you need it, you could begin to load it progressively when we come close to it. This progressive load would reduce a bit the speed but would make the "loading" disappear.
And I'm not sure what you mean by "even though it reduces the speed".
LOL! It supports TI-NSPIRE CAS number!
It worked great! While I prefer the original material.
Speaking of multitasking. You know what I think would be fun, and awesome but probably isn't likely or possible(or already has been done in which case I'm an idiot and stop reading this)? Threads for calcs.Yes, it has already been done (https://github.com/tangrs/nspire-multithreading-poc), but it has much overhead.
But the real question is do they have GPU's?That depends on your definition of GPU.. The LCD controller (PL110) can do some basic things itself, but nothing useful.
I'm way to lazy to check or ask if this is at all possible or whether or not it has or has not been done. This post is actually more of me showing my appreciation of the challenges of multi-threaded process/rendering.Yep, that's really the case. Multithreading can be a PITA..
Anyway, AWESOME game/engine/thingi Vog, I haven't been checking up on it for a while but it looks GREAT!Thanks!
File access is SLOW. Slower than generating chunks on-the-fly. That's why I just load every Chunk in the savefile directly at the splash screen..Why, then, does it have to load all the generated chunks at start? Can't you just load selective parts of the file into memory, accessing like an array? (Guessing you don't have arbitrarily large block data yet, but you could still stick that at the end (found by a position dictated in the header of the save).)That's basically how it works now...Not really. I could generate 10MB of Chunks and use that, but it'd take 10 minutes to generate and also 10 minutes to load each time you want to play.I was asking if instead of loading a block of map each time you need it, you could begin to load it progressively when we come close to it. This progressive load would reduce a bit the speed but would make the "loading" disappear.
And I'm not sure what you mean by "even though it reduces the speed".
Ninja edit: It looks awesome. :D Nice work.Tee-eitch-ex!
大声笑!它支持TI-NSPIRE CAS号!Great to hear that it works on HW as well as on nspire_emu :D
它的工作太棒了!虽然我喜欢原来的材料 .
Also, most of us don't speak chineese ;)At my school the teachers can now take chinese lessons for free. God knows why, but my history teacher really annoys me.
It's not that big of a problem ;)You could use the free 8 bits for power level.
Currently, BLOCK_WDATA is defined as uint16_t, the lowest 8 bits are the BLOCK (the ID),
the higher 8 bits could be used for anything.
Somewhere in crafti, there's the enum BLOCK_SIDE, which is used as the highest 8 bits of the door's BLOCK_WDATA.
To indicate whether it's the top or bottom half of a door, bit 7 is used.
For redstone power state, I'd use the top 2 bits (7 and 6) and I'd have to move the door part bit out of the way.
Then each door part would have it's part bit set to 0, which is bottom..
Edit: So that old doors won't confuse redstone circuits:
enum REDSTONE_STATE {
NOT_POWERED=0b00,
PASSIVELY_POWERED=0b01,
NOT_POWERED_2=0b10,
ACTIVELY_POWERED=0b11,
}; or even better, a bitfield.
can you imagine, redstone computers on your Nspire?Better, a redstone calculator on your calculator O.O.
Which 8 free bits?
It's not that big of a problem ;)
Currently, BLOCK_WDATA is defined as uint16_t, the lowest 8 bits are the BLOCK (the ID),
the higher 8 bits could be used for anything.
Somewhere in crafti, there's the enum BLOCK_SIDE, which is used as the highest 8 bits of the door's BLOCK_WDATA.
enum BLOCK_SIDE {
BLOCK_FRONT=0,
BLOCK_BACK,
BLOCK_LEFT,
BLOCK_RIGHT,
BLOCK_TOP,
BLOCK_BOTTOM
};
Edit: I just reseted the votes, removed lighting (doesn't work together with face-combining) and added minecarts (why not?)
I could allocate some more, but I thought (e)ndless redstone would work better and is less annoying.With normal redstone, though, we can port "real" redstone devices easier.
Both! Both tested, but 3.6 not regularily. The only ndless functions I use are hwtype(), isKeyPressed and fopen/fread/fwrite/fclose.ok cool to hear, because I didn't feel like upgrading to OS 3.6 yet. :P
Edit: I just reseted the votes, removed lighting (doesn't work together with face-combining) and added minecarts (why not?)
ok cool to hear, because I didn't feel like upgrading to OS 3.6 yet. :PLol, you are not at all alone to do so. :p
Why do you need bits for opened or closed doors? Can't you just make a block which is an opened door and an other one which is a closed one ?
Just the comparator, nothing more. And I don't think you'd build really complex machinery on crafti..I could allocate some more, but I thought (e)ndless redstone would work better and is less annoying.With normal redstone, though, we can port "real" redstone devices easier.
V.I am, just vote for mobs in the poll at the top. But currently it seems you're lucky :)
Are u planning on adding mobs into the game at any point because that will make the game a bit more interesting
but good job
:D
Vogtinator, you probably forgot my question:I answered it, directly below. It wouldn't make any sense NOT to use the BLOCK_DATA bits as that's basically their purpose.Why do you need bits for opened or closed doors? Can't you just make a block which is an opened door and an other one which is a closed one ?
The world size I refer to is the size of the discovered part. If you walk too far from the spawn point, it'll crash soon.Couldn't you use gotos once the world reached a certain size instead of exceptions?
The right way to prevent this is to cancel if memory allocation fails, but in C++ this works only with exceptions, which don't work with bFLT yet.
Question: In the menu, how are we supposed to save? When choosing save I tried the Menu, dot, 5, esc and Enter keys and whichever worked doesn't appear to save properly. When I restart the game and try to reload the map, it does nothing so I lose all my progress.Just press "menu" then either the touchpad or clickpad "click" or the 5 key. It should freeze for a short time and then close the menu.
Just a quick update:AWESOME!!!
I'm currently busy on vacation and next week school starts again so I'm busy learning and other unnecessary duties.
Redstone is fully implemented, but some blocks are still missing, so it's not very useful yet.
However, I worked a bit on my ndless fork and got exceptions to work! It's a rather nice feature, to minimize possible crashes.
Also, it'll be using a new executable format which will load faster and maybe also make the game faster!
It'll take a while to implement it in both ndless 3.6 and 3.1 though, I don't want that it runs on 3.6 only.
However, I worked a bit on my ndless fork and got exceptions to work! It's a rather nice feature, to minimize possible crashes.Nice !
Also, it'll be using a new executable format which will load faster and maybe also make the game faster!
It'll take a while to implement it in both ndless 3.6 and 3.1 though, I don't want that it runs on 3.6 only.
nGL renders only triangles, so is much more flexible in drawing textures at an arbitrary scale, rotation, translation etc., but that comes at the cost of:Well I personnally didn't know about your 2D lib until recently (after n2Dlib was started) but you should definitely havewhich wouldn't be necessary for simple 2D stuff. That's also the reason I wrote a basically seperate lib "texturetools.cpp" to do 2d transformations (basically blitting, scaling, font etc.) on TEXTUREs. And yes, it's faster than n2dlib ;)
- Clipping
- Culling
- Z-Buffer
- Interpolation along X and Y-Axis (With textures: 3 divisions per scanline, without: 1)
^ That.nGL renders only triangles, so is much more flexible in drawing textures at an arbitrary scale, rotation, translation etc., but that comes at the cost of:Well I personnally didn't know about your 2D lib until recently (after n2Dlib was started) but you should definitely havewhich wouldn't be necessary for simple 2D stuff. That's also the reason I wrote a basically seperate lib "texturetools.cpp" to do 2d transformations (basically blitting, scaling, font etc.) on TEXTUREs. And yes, it's faster than n2dlib ;)
- Clipping
- Culling
- Z-Buffer
- Interpolation along X and Y-Axis (With textures: 3 divisions per scanline, without: 1)
bragged :Ptold about it sooner. The goal of n2Dlib was not to make something new, just to make a lib that runs at the same speed on CXes and non-CXes (and also that used the same format for "sprites" as nSDL). And apparently, not only it's slower on CXes but it's not even fast on the fastest model -.-
So could you share a link to your 2D lib and to a documentation about it ?
#include <libndls.h>
#include "texturetools.h"
#include "font.h"
int main()
{
TEXTURE *screen = newTexture(SCREEN_WIDTH, SCREEN_HEIGHT);
nglInit();
nglSetBuffer(screen->bitmap);
while(!isKeyPressed(KEY_NSPIRE_ESC))
{
//Draw
glColor3f(0, 0, 0);
glClear(GL_COLOR_BUFFER_BIT);
drawString("Hi!\nThis is a small test!", 0xFFFF, *screen, 0, 0);
nglDisplay();
}
nglUninit();
deleteTexture(screen);
}
Okay so stop saying texturetools is faster than n2DLib : I just looked at your drawTexture routine, it's exactly the same as n2DLib's drawSpriteIt isn't (probably a typo, but drawTexture = drawSpritePart). I know, I probably sound like an asshole now (:-\), but I already told you how you could optimize it:
8e28: e15392b4 ldrh r9, [r3, #-36] ; 0xffffffdc
8e2c: e14292b4 strh r9, [r2, #-36] ; 0xffffffdc
8e30: e15392b2 ldrh r9, [r3, #-34] ; 0xffffffde
8e34: e14292b2 strh r9, [r2, #-34] ; 0xffffffde
Well, two of us come from Axe and care less about readability than about speed (even though it seems like we are not Nspire pros :P) or efficiency.
- Use a Texture struct rather than a unsigned short* for better readability.
It isn't (probably a typo, but drawTexture = drawSpritePart). I know, I probably sound like an asshole now ( :/ ), but I already told you how you could optimize it.
It should compile to the same code. If not, it could be faster due to alignment if you use a "flexible array member" (StackOverflow question (http://stackoverflow.com/questions/2060974/dynamic-array-in-struct-c))Well, two of us come from Axe and care less about readability than about speed (even though it seems like we are not Nspire pros :P ) or efficiency.
- Use a Texture struct rather than a unsigned short* for better readability.
Edit: I didn't downvote you. I really like discussions both sides benefit from.
Well that answers the "speed problem", but not the "efficiency" one because to convert the tab into a struct, well there is a need for a function to convert the tab into a struct -.-It should compile to the same code. If not, it could be faster due to alignment if you use a "flexible array member" (StackOverflow question (http://stackoverflow.com/questions/2060974/dynamic-array-in-struct-c))Well, two of us come from Axe and care less about readability than about speed (even though it seems like we are not Nspire pros :P ) or efficiency.
- Use a Texture struct rather than a unsigned short* for better readability.
Also, I was once told by a moderator that even if a n00b is being annoying or someone spams that it's against the rules to be agressive, so on Omni, if you question people's reading skills, tell members they have no brain, yell at them using cussing and all-caps or try to make them look stupid/inferior, then you cannot use any excuse to get away with it (the only way to get away with it is if you don't get caught). This is more an head-up, because in the past I got banned for being rude too (although not for very long) and you can see my rating ratio as an indicator.I would not even say "on Omni" only. It's not constructive to be angry, whether on Omni or IRL or anywhere. When there is someone angry in a discussion, it only makes the other people angry. And when you tell people they have no brain, especially when you are the one to blame and not the others, it only makes them defend themselves about this free insult before contributing to the real discussion, and I would even say "instead of" instead of "before" because once they defended themselves they don't really want to discuss with you anymore.
and starting a pissing contest about which lib is better or not and doing so in someone else's lib thread.Yeah, I didn't expect that.
I find it legitimate to be angry when people keep bashing my work and saying without any stats to prove it "yes my lib is faster than his lib".You asked me on IRC TWICE how you could optimize it further, I answered you and you ignored it, except for the "unsigned int" as x/y part. I even provided a nice list of suggestions but you ignored it again. If you don't want to implement it, don't say that your lib is faster. Not using "-Ofast" or at least "-O2" is just ignorant.
Moreover, I keep proving my lib is not slow, but people keep ignoring meWhich "people"?
and seeing it as the slowest thing of the universe, at the point that they'll take any other lib instead of it.Your lib isn't slow in the meaning of "too slow". I never meant that. I just implied it could be much faster.
Of course, if someone does test and proves by a + b that Vogtinator's lib is faster than mine at an identical task, then no problem. But just stating it with no numbers of any kind is insulting.Well, I don't need any benchmarks to compare multiple comparisions, branches and additions to a single increment.
Well that answers the "speed problem", but not the "efficiency" one because to convert the tab into a struct, well there is a need for a function to convert the tab into a struct -.-No reason to do anything like that, it's directly binary-compatible ;)
struct Texture {
uint16_t width;
uint16_t height;
uint16_t transparent_color;
uint16_t bitmap[];
} __attribute__((packed));
could work. Untested.or blaming it for nKaruga slowdowns on CX models (even though we all saw what happened with the transition from 84+SE to 84+CSE).That's not his fault, that's the hardware and it will be the exact same with nGL (may be a little bit faster as nGL doesn't invert each sprite, but rather the entire screen once before it's drawn).
think it might be a better idea to use a different texture for the selected block since I tend to get confused with actual glass windows and stuff. Would a square with nothing except an outline that slowly flashes between black and white be better?Yay, on-topic again! Seems like I should use my graphics tablet again.
<off-topic again sorry, but got to clear that up>Looks better, but still a lot to improve! (any branch per pixel, for instance if(has_color) definitely needs to go!)
Okay so I finally have a computer again, so I worked on n2DLib after several days when I couldn't. So I tried to implement your suggestions as good as I could.
First, sorry for being angry like this. I know it's ridiculous and shit, but I just had enough of seeing people implying the lib was supposedly slow. (and Vogtinator I never meant you, I know aeTIos kept saying it some time ago although he stopped now ; or maybe I'm just being too proud or paranoid, don't know which).Well, then I wonder why you posted here.. To tell everybody my lib was slow as well/as fast as yours?
Anyway, well, it's a lib, so compile flags are up to the user.Yeah, but then you should use the correct flags for your example, it's an example after all..
DJ : I didn't want to start a war about what lib was better, I was just asking please stop assuming my lib is slow without even trying it or wondering if that's not your code's fault x.x I remember some days ago on IRC, Streetwalrus was saying something like "tetris is slow, it's n2DLib's fault" and was serious about it, and of course it turned out the problem was his own code. The fact itself isn't really important, it's just the way of thinking that's annoying. But let's forget that and pretend it never happened.That's the reason nGL allocates a third buffer on monochrome calcs (yup, one on CX and three on non-CXs)!
Vogtinator : for your optimizations, I do remember me asking you some, but I don't know, maybe I was working on something else at that moment so I forgot afterwards <_< I did my best at implementing them this time, it should be visible in github's history.
Although I find it a good idea, I can't afford inverting the buffer only when updateScreen-ing depending on the screen model, because maybe one day someone will not want to erase the buffer each frame and that will give weird results.
So I guess that's it, sorry for the off-topic, sorry for being upset, sorry for saying stupid shit, things like that.No, definitely not! You can't swin in lava and water needs to be at least two blocks deep to swin in.
Back on-topic, when testing the last version on an emulated TI-Nspire CX CAS with Ndless 3.1 r914, I noticed you couldn't swim in water nor lava, is that intended ?
Well, you answered yourself to the problem :P I'll do that too, coming from the z80 scene I'm always very afraid of allocating lots of memory.<off-topic again sorry, but got to clear that up>Looks better, but still a lot to improve! (any branch per pixel, for instance if(has_color) definitely needs to go!)
Okay so I finally have a computer again, so I worked on n2DLib after several days when I couldn't. So I tried to implement your suggestions as good as I could.QuoteAlthough I find it a good idea, I can't afford inverting the buffer only when updateScreen-ing depending on the screen model, because maybe one day someone will not want to erase the buffer each frame and that will give weird results.That's the reason nGL allocates a third buffer on monochrome calcs (yup, one on CX and three on non-CXs)!
320*240*2 = ~155KB, that's almost nothing.
That "by the way, it's faster than n2DLib" just sitting here without any further development really made me upset.QuoteFirst, sorry for being angry like this. I know it's ridiculous and shit, but I just had enough of seeing people implying the lib was supposedly slow. (and Vogtinator I never meant you, I know aeTIos kept saying it some time ago although he stopped now ; or maybe I'm just being too proud or paranoid, don't know which).Well, then I wonder why you posted here.. To tell everybody my lib was slow as well/as fast as yours?
Woops, I actually forgot that.QuoteAnyway, well, it's a lib, so compile flags are up to the user.Yeah, but then you should use the correct flags for your example, it's an example after all..
Ah, it wasn't 2 blocks deep, but I thought that in the original Minecraft, you could swim on top of a water cube even if it was all alone ; here it just jumps.QuoteSo I guess that's it, sorry for the off-topic, sorry for being upset, sorry for saying stupid shit, things like that.No, definitely not! You can't swin in lava and water needs to be at least two blocks deep to swin in.
Back on-topic, when testing the last version on an emulated TI-Nspire CX CAS with Ndless 3.1 r914, I noticed you couldn't swim in water nor lava, is that intended ?
I just tested and it works for me :-/
Edit: Is it permitted to double-post to seperate a release announcement from the rest?Yep.
And there's still more to optimize. Partial loop unrolling as 2x16bit access is slower than 1x32bit for example.
To give you an example of a almost fully optimized function, I optimized drawTexture some more: https://github.com/Vogtinator/crafti/blob/master/texturetools.cpp#L151 (https://github.com/Vogtinator/crafti/blob/master/texturetools.cpp#L151)
GCC does some partial unrolling, but doesn't transform 2 16bit accesses (ldrh/strh) to 32bit access(ldr/str), although -Ofast should do something, should I report a bug?Code: [Select]8e28: e15392b4 ldrh r9, [r3, #-36] ; 0xffffffdc
8e2c: e14292b4 strh r9, [r2, #-36] ; 0xffffffdc
8e30: e15392b2 ldrh r9, [r3, #-34] ; 0xffffffde
8e34: e14292b2 strh r9, [r2, #-34] ; 0xffffffde
COLOR *dest_ptr = dest.bitmap + dest_x + dest_y * dest.width, *src_ptr = src.bitmap + src_x + src_y * src.width;
dest_ptr might be src_ptr + 1 ( *src_ptr is not const ) so moving two texels for this case will produce different results.And there's still more to optimize. Partial loop unrolling as 2x16bit access is slower than 1x32bit for example.
To give you an example of a almost fully optimized function, I optimized drawTexture some more: https://github.com/Vogtinator/crafti/blob/master/texturetools.cpp#L151 (https://github.com/Vogtinator/crafti/blob/master/texturetools.cpp#L151)
GCC does some partial unrolling, but doesn't transform 2 16bit accesses (ldrh/strh) to 32bit access(ldr/str), although -Ofast should do something, should I report a bug?Code: [Select]8e28: e15392b4 ldrh r9, [r3, #-36] ; 0xffffffdc
8e2c: e14292b4 strh r9, [r2, #-36] ; 0xffffffdc
8e30: e15392b2 ldrh r9, [r3, #-34] ; 0xffffffde
8e34: e14292b2 strh r9, [r2, #-34] ; 0xffffffde
There are actually two reasons why a compiler cannot use 32bit memory move instructions here.
1:Code: [Select]COLOR *dest_ptr = dest.bitmap + dest_x + dest_y * dest.width, *src_ptr = src.bitmap + src_x + src_y * src.width;
dest_ptr might be src_ptr + 1 ( *src_ptr is not const ) so moving two texels for this case will produce different results.
2:
It is not guaranteed that src_ptr and dest_ptr are each aligned to 4 byte which is required if you want to move 4 byte at a time on ARM.
From my POV you ignored my hints and I just had to write it, sorry.That "by the way, it's faster than n2DLib" just sitting here without any further development really made me upset.QuoteFirst, sorry for being angry like this. I know it's ridiculous and shit, but I just had enough of seeing people implying the lib was supposedly slow. (and Vogtinator I never meant you, I know aeTIos kept saying it some time ago although he stopped now ; or maybe I'm just being too proud or paranoid, don't know which).Well, then I wonder why you posted here.. To tell everybody my lib was slow as well/as fast as yours?
DJ : I didn't want to start a war about what lib was better, I was just asking please stop assuming my lib is slow without even trying it or wondering if that's not your code's fault x.x I remember some days ago on IRC, Streetwalrus was saying something like "tetris is slow, it's n2DLib's fault" and was serious about it, and of course it turned out the problem was his own code. The fact itself isn't really important, it's just the way of thinking that's annoying. But let's forget that and pretend it never happened.When did I say that ? ??? I was just jokingly saying that n2DLib's 4K was big, which it obviously isn't.
Will pistons, comparators, and repeaters and the like be implemented?Comparators have nothing to compare and repeaters nothing to repeat: Redstone in crafti is infinite!
Also that looks great does it still work on GS calcs which use the 3.1 version of Ndless, since you now use another executable format ?It should even run on some versions < 3.1, I'm not using much except fopen etc. at all.
Actually repeaters still have two uses: delayers and diodes. They let you delay by one tick while torches need two ticks (since you need to re-invert the signal).Looks like I haven't played minecraft in a while.. Added to the TODO list, but below everything else as not really necessary.
What I meant is since torches invert the signal, you need two of them to make a repeater, and then it's a two ticks repeater.Oh, now I realized what you meant, I should really go to bed now ._.
Wow, that redstone implementation looks sick! I really need to give the new version a try when I have time :)The implementation IS sick. Just look at the code :P
I just had a question when reading your post. What is format Zehn ? I only get redirected to German pages when I google it o.oYou know ELF, right? Elf is German for eleven and Zehn is German for ten, that should explain it :)
Do you plan a ticalc.org update soon?Hm, why not?
Ok, thanks :)QuoteI just had a question when reading your post. What is format Zehn ? I only get redirected to German pages when I google it o.oYou know ELF, right? Elf is German for eleven and Zehn is German for ten, that should explain it :)
Basically it's a custom format without the restrictions of bFLT which should load faster and supports code without PIC and with exceptions.
Also wow, I just updated crafti on my calc and it's really great (not that it was bad before )You can rotate faster if you press the touchpad - this is also dependant on your "Speed" setting. I didn't make the "rubbing" speed change with "Speed", as it would be impossible or too hard to aim on fastest speed.
There is just something that annoys me a bit. Would it be possible to have a higher touchpad sensitivity ? Because I have to rub it 5 times before seeing what's behind me
Of course, you can make it an option to have both precision-people and speed-people happy
Probably taken from running the game in nspire_emu. (well, at least it's the quickest way to get it)Correct, and the gifs are made using byzanz-record. I move the window to the coords 0/0 and start it with "-x 0 -y 0 -w 320 -h 240".
Although a screenshot feature within the game would be cool (if it's not there already, I don't know )I had implemented it once but lost the code somehow (it was before v0.7.2, when I moved to git). But it's on my todo list again!
Maybe a part of that could help (instead of recoding this feature from scratch) : http://tiplanet.org/forum/archives_voir.php?id=12264QuoteAlthough a screenshot feature within the game would be cool (if it's not there already, I don't know )I had implemented it once but lost the code somehow (it was before v0.7.2, when I moved to git). But it's on my todo list again!
Could it be possible though to have it save in screenshotXXX.ppm.tns, where XXX ranges from 000 to 999 ? In case we have to do more than one screenshot while we are on vacationsThat could get slow, but why not. I'll also add some kind of notification ("Saved as %d.ppm") on the screen.
Also, about the sensitive touchpad (yeah, again ), couldn't it be possible to have the "center zone" of the touchpad be precise, and the "outer zone" be fast ?That could be weird if you wipe across the pad and it gets slower in the center. But I'll probably make the rotation speed dependant on the touchpad velocity.
Well, only slow while saving, so not a big problem as long as it doesn't last ;)QuoteCould it be possible though to have it save in screenshotXXX.ppm.tns, where XXX ranges from 000 to 999 ? In case we have to do more than one screenshot while we are on vacationsThat could get slow, but why not. I'll also add some kind of notification ("Saved as %d.ppm") on the screen.
But I'll probably make the rotation speed dependant on the touchpad velocity.Yeah, very good idea, I don't even know why I didn't think about it :D
Could be cool though it's too bad that it is said nowhere that the first game to use this concept was Eco-Sphere on PSP, several years ago.Not echochrome? It was boring as hell...
Or if your engine supports sloppy terrain you could do Reuben Quest 3D(https://wheredreamscollide.files.wordpress.com/2012/05/no-meme.jpg)
Looks like fun indeed ^^Like in Crafti?
But I don't know how you'll do a convenient camera movement without a mouse.
Otherwise, you can also make a Portal game if you lack ideas :PI thought about that but without physics, large levels and some complex mechanics it wouldn't be fun. Perspective is quite simple and can also be fun with smaller levels.
Yeah well I didn't quite remember the name and went pretty random it's indeed Echochrome, and well if it's boring, then Perspective is boring, since it's pretty much the same game.Not really. On echochome you can only control the camera, the weird walking things were controlled by the computer.
I saw the textures in crafti were a little wonky (maybe for speed reasons), are there any texture routine more accurate?Depends on what you mean by "wonky". Some inaccuracies are due to the fixed point math.
Finally, Crafti gets its ticalc news feature http://www.ticalc.org/archives/news/articles/14/148/148684.html (http://www.ticalc.org/archives/news/articles/14/148/148684.html):w00t: I uploaded the latest version some months ago so this is a real surprise for me.
Also I need to check the latest version at one point because I think what I got is an older version.That's fairly simple, the latest version doesn't have the ugly black gradient with 50% opacity menu.
Aw, I liked that menu for some reasons D:Oh, I just noticed I didn't change the menu at all in v1.1, the ugly black menu is gone since v1.0. For comparision:
Old:(http://i.imgur.com/jq4svm6.gif) | New:(http://img.ourl.ca/crafti_v1.0_menu.png) |
Oh right yeah that menu. I like the new one actually. I thought you meant the items menu at first. :PAw, I liked that menu for some reasons D:Oh, I just noticed I didn't change the menu at all in v1.1, the ugly black menu is gone since v1.0. For comparision:
Old:(http://i.imgur.com/jq4svm6.gif) New:(http://img.ourl.ca/crafti_v1.0_menu.png)
Question: is nGL (the library) not on GitHub? I'd really like to use it, after seeing how powerful it is.A quick search didn't come up with anything: https://github.com/search?q=nGL%20nspire&type=Everything&repo=&langOverride=&start_value=1
Click on "Code" :PQuestion: is nGL (the library) not on GitHub? I'd really like to use it, after seeing how powerful it is.A quick search didn't come up with anything: https://github.com/search?q=nGL%20nspire&type=Everything&repo=&langOverride=&start_value=1
Yay thanks!It's up on https://github.com/Vogtinator/nGL. I added a "lib" taget to the Makefile so you can use it from within a subdirectory. If you need help, just write a PM :)
Now to begin work on my secret project. :D
/me derpsClick on "Code" :PQuestion: is nGL (the library) not on GitHub? I'd really like to use it, after seeing how powerful it is.A quick search didn't come up with anything: https://github.com/search?q=nGL%20nspire&type=Everything&repo=&langOverride=&start_value=1
You should add "Nspire" to the repo description at least. :)Yay thanks!It's up on https://github.com/Vogtinator/nGL. I added a "lib" taget to the Makefile so you can use it from within a subdirectory. If you need help, just write a PM :)
Now to begin work on my secret project. :D
Crafti is last year's ticalc POTY! ;D
(http://www.ticalc.org/images/poty/2014-nspire-big.gif) (http://www.ticalc.org/community/awards/poty/2014.html#3)
Huge thanks to everone voting for me :-*
The competition was strong, I expected nQuake to score much higher.
Also, I've been working on the next release for some time already, but it's not going to be finished soon, I'm busy with school stuff and in a few months, work.
Edit: Over 1000 downloads, >700 on ticalc alone!
I finally got around to writing a tutorial on how to use nGL: http://github.com/Vogtinator/nGLThat would be great if you made a tutorial about texture mapping.
That would be great if you made a tutorial about texture mapping.Will do, that's the next step :)
Also, does anyone know if nGL is faster for 2D stuff than n2DLib ?The 3D parts definitely not. Although it's faster on desktop machines to use orthogonal projection for 2D rendering as that's hardware accelerated,
I finally got around to writing a tutorial on how to use nGL: http://github.com/Vogtinator/nGLYay tutorials! Now to make some cool stuff with nGL!
Maybe we'll see some more 3D games on the nspire now!
Yeah well people wouldn't stop talking shit about how n2DLib was slower than nGL even though not a single test was ever made.I would make a test, but n2DLib doesn't support TEXTURE-TEXTURE blitting what nGL does. Although that shouldn't make a huge difference, it'll be unfair.
You optimized it ? Oh yeah cool, so did pierrotdu18, Hayleia and I.Well, I'm sorry to say, but it just doesn't look like it.
00000a80 <setPixel>:
a80: e35100ef cmp r1, #239 ; 0xef
a84: 93500d05 cmpls r0, #320 ; 0x140
a88: 33a03d05 movcc r3, #320 ; 0x140
a8c: 30210193 mlacc r1, r3, r1, r0
a90: 359f300c ldrcc r3, [pc, #12] ; aa4 <setPixel+0x24>
a94: 31a01081 lslcc r1, r1, #1
a98: 35933000 ldrcc r3, [r3]
a9c: 318320b1 strhcc r2, [r3, r1]
aa0: e12fff1e bx lr
aa4: 00011078 .word 0x00011078
In drawSprite:
c94: e1550008 cmp r5, r8
c98: e08b3005 add r3, fp, r5
c9c: aa000008 bge cc4 <drawSprite+0x68>
ca0: e0da20b2 ldrh r2, [sl], #2
ca4: e1d630b4 ldrh r3, [r6, #4]
ca8: e1530002 cmp r3, r2
cac: 0a000002 beq cbc <drawSprite+0x60>
cb0: e1a01004 mov r1, r4
cb4: e1a00005 mov r0, r5
cb8: ebffff70 bl a80 <setPixel>
cbc: e2855001 add r5, r5, #1
5a0: e25cc001 subs ip, ip, #1
5a4: 3a000005 bcc 5c0 <drawTexture(...)+0x158>
5a8: e0d560b2 ldrh r6, [r5], #2
5ac: e1d080b6 ldrh r8, [r0, #6]
5b0: e2811002 add r1, r1, #2
5b4: e1580006 cmp r8, r6
5b8: 114160b2 strhne r6, [r1, #-2]
As that code is run per pixel, I guess that that is definitely a noticable difference.
You optimized it ? Oh yeah cool, so did pierrotdu18, Hayleia and I.Wut ? I don't know about pierrot and you but I didn't do anything. I pretty much dropped the project when I saw one of you was not putting brackets for one-instruction blocks, even when it's a for in a for (which leads to very ugly code in my opinion).
For easier comparision, here are the two inner loops of drawSprite and the nGL equivalent, compiled with the same flags as your example:Code: [Select]...
As that code is run per pixel, I guess that that is definitely a noticable difference.
Sadly both routines appear to be quite unoptimized.I guess you could make it faster by doing 32-bit transfers, but the shortest asm version with word-transfers is the nGL version minus
ldrh r8, [r0, #6]
, because that should happen outside of the loop and r1 could be used as counter instead of r12.loop:
ldrh r3, [r0], #2
strh r3, [r1], #2
cmp r0, r2
bne loop
Also, 32bit transfers would be impossible if source or dest aren't 32-bit aligned which isn't the case if you have an uneven X.
loop:
ldrh r3, [r0], #2 | 1
strh r3, [r1], #2 | 2-4 ( 2 cycles of 2 cycle interlock on r3 )
cmp r0, r2 | 5
bne loop | 6-8
So, for example, unrolling the loop would help quite a bit.It would, but as I said, only possible if Xsrc % 2 == Xdest % 2, so not widely applicable.
8 Cycles for copying a single pixel without any transformation is way too much.
8 Cycles for copying a single pixel without any transformation is way too much.Yeah, but I guess you can't do much about it without using Asm (and I target not to, except if there are very obvious improvements).
Given your example, which seems to copy without the transparency check, we end up with something this ( cycle estimate at end of line ):I guess it could be improved by one cycles if the cmp is moved between the ldrh/strh?
void blit_pels( const int16_t *pp_srcB, int32_t i_src_stride, int16_t *pp_dstB, int32_t i_dst_stride, int32_t i_width, int32_t i_height )
{
int32_t i_y;
for( i_y = 0; i_y < i_height; i_y++ )
{
int16_t pp_a0, pp_a1, pp_a2, pp_a3;
const int16_t *pp_src;
int16_t *pp_dst;
int32_t i_remain4, i_remain1;
pp_src = pp_srcB;
pp_dst = pp_dstB;
i_remain4 = i_width >> 2;
while( i_remain4 > 0 )
{
pp_a0 = *( pp_src++ );
pp_a1 = *( pp_src++ );
pp_a2 = *( pp_src++ );
pp_a3 = *( pp_src++ );
*( pp_dst++ ) = pp_a0;
*( pp_dst++ ) = pp_a1;
*( pp_dst++ ) = pp_a2;
*( pp_dst++ ) = pp_a3;
i_remain4--;
}
i_remain1 = i_width & 3;
while( i_remain1 > 0 )
{
pp_a0 = *( pp_src++ );
*( pp_dst++ ) = pp_a0;
i_remain1--;
}
pp_srcB += i_src_stride;
pp_dstB += i_dst_stride;
}
}
Somehow I was thinking about 32-bit access here, I don't know why.QuoteSo, for example, unrolling the loop would help quite a bit.It would, but as I said, only possible if Xsrc % 2 == Xdest % 2, so not widely applicable.
8 Cycles for copying a single pixel without any transformation is way too much.
... 32-bit access ...
(http://i.imgur.com/cqkOsWc.png) | Improvements in crafti (https://github.com/Vogtinator/crafti):
|
(http://i.imgur.com/Db2REly.gif) | Improvements in nGL (https://github.com/Vogtinator/nGL):
|