Crafti v1.2(Original thread with old versions and history on omnimaga: https://www.omnimaga.org/ti-nspire-projects/ngl-a-fast-(enough)-3d-engine-for-the-nspire)
No major changes, just some bugfixes and improvements.
I haven't tested classic support extensively, so if you're relying on that you should keep your old version around.
On a HW-W calc this should improve usability significantly, so please upgrade!
Download on GitHub (https://github.com/Vogtinator/crafti/releases/tag/v1.2)
(http://i.imgur.com/cqkOsWc.png)
|
|
|
|
Improvements in crafti (https://github.com/Vogtinator/crafti):
- Bugfix: Division by 0 when calculating collision while looking straight ahead
- Zehn compression for faster startup and less space requirements
|
(http://i.imgur.com/Db2REly.gif)
|
|
|
|
Improvements in nGL (https://github.com/Vogtinator/nGL):
- Several performance improvements
- Uses lcd_blit, so works natively on HW-W
- On PC, use SDL for graphics
- Add tools for converting wavefront obj
- Add VECTOR3 and nglDrawArray
- Add two new lessons to the tutorial (https://github.com/Vogtinator/nGL/tree/master/Tutorial)
|
I didn't knew this was still alive. I'm glad to see new updates to Crafti and nGL. :) Speed and size improvements are always welcome.
Also that Spongebob model looks amazing for a calculator :)
Wow! nice job Voginator ;)
I feel like bumping this thread because this new version of crafti and nGL helped me porting it to the GCW0 with input controls.
Your initial SDL port didn't have controls, which i had to implement.
Source code with OPK is here :
https://github.com/gameblabla/crafti (https://github.com/gameblabla/crafti)
I also had to fix some bugs with crafti.
For example, at higher resolutions, the inventory menu doesn't control properly so i have fixed that.
https://github.com/gameblabla/crafti/commit/cf276fa527ed4e25981a2209f09b215ba62ea1c3 (https://github.com/gameblabla/crafti/commit/cf276fa527ed4e25981a2209f09b215ba62ea1c3)
Playing it on my zero, it runs much faster than on my nspire but i eventually found a bug
where if you go far enough, the textures will severely bleed.
I'm not sure how it can be fixed though : maybe extending the world ?
QuoteYour initial SDL port didn't have controls, which i had to implement.
Thanks! I never bothered to do so because it was mainly just for engine testing and performance tuning
(valgrind and perf on a raspberry pi)
QuoteFor example, at higher resolutions, the inventory menu doesn't control properly so i have fixed that.
Yeah, I never bothered with that either, at some places I hardcoded coordinates.
QuotePlaying it on my zero, it runs much faster than on my nspire but i eventually found a bug
where if you go far enough, the textures will severely bleed.
I'm not sure how it can be fixed though : maybe extending the world ?
If it runs fast enough, you can tune some settings in glconfig.h, especially BETTER_PERSPECTIVE.
It's great that you were able to port it, can you clean your port up a bit and submit a pull request?
I am curious about how it looks like on the GCW0 :)
Quote from: Vogtinator on October 01, 2016, 09:20:24 AM
If it runs fast enough, you can tune some settings in glconfig.h, especially BETTER_PERSPECTIVE.
Sadly, i had already enabled this and it doesn't fix anything.
When i have enabled SAFE_MODE, it spams my terminal with this :
Warning : Texture coord out of bounds !
And here does it look like on my GCW0 (and PC) :
(https://gameblabla.nl/img/crafti-bug1.png)
(https://gameblabla.nl/img/crafti-bug2.png)
The map file also becomes much bigger.
Maybe it is a good idea to add insivible walls ?
QuoteI am curious about how it looks like on the GCW0 :)
I might do a video on that video but(t) basically, it's the nspire version running much faster.
Lately, i have also added some sound effects and music.
QuoteIt's great that you were able to port it, can you clean your port up a bit and submit a pull request?
Hmm... That will take some time because i changed my git repo a quite bit compared to yours.
But i will look into it.
Quote from: gameblabla on October 01, 2016, 10:05:42 PM
Quote from: Vogtinator on October 01, 2016, 09:20:24 AM
If it runs fast enough, you can tune some settings in glconfig.h, especially BETTER_PERSPECTIVE.
Sadly, i had already enabled this and it doesn't fix anything.
When i have enabled SAFE_MODE, it spams my terminal with this :
Warning : Texture coord out of bounds !
And here does it look like on my GCW0 (and PC) :
(https://gameblabla.nl/img/crafti-bug1.png)
(https://gameblabla.nl/img/crafti-bug2.png)
Hm, that means there was a division by close-to-zero in the perspective divide.
It should be gone if you decrease the rendering distance, although it shouldn't
occur that often with BETTER_PERSPECTIVE... Did you run make clean?
QuoteThe map file also becomes much bigger.
Maybe it is a good idea to add insivible walls ?
Why?
Quote
QuoteIt's great that you were able to port it, can you clean your port up a bit and submit a pull request?
Hmm... That will take some time because i changed my git repo a quite bit compared to yours.
But i will look into it.
It's much appreciated!
Quote from: Vogtinator on October 02, 2016, 08:38:46 AM
Hm, that means there was a division by close-to-zero in the perspective divide.
It should be gone if you decrease the rendering distance, although it shouldn't
occur that often with BETTER_PERSPECTIVE... Did you run make clean?
Yes, i ran make clean several times my sweety but it is still there.
Decreasing the rendering distance doesn't seem to do much...
Same with BETTER_PERSPECTIVE.
Quote from: Vogtinator on October 02, 2016, 08:38:46 AM
Why?
So It happens less often ?
I admit i'm not quite sure what causes this to happen but you can see it only bleeds in the blue sky background...
Any idea for a workaround ?
Quote from: gameblabla on October 02, 2016, 10:19:27 PM
Quote from: Vogtinator on October 02, 2016, 08:38:46 AM
Hm, that means there was a division by close-to-zero in the perspective divide.
It should be gone if you decrease the rendering distance, although it shouldn't
occur that often with BETTER_PERSPECTIVE... Did you run make clean?
Yes, i ran make clean several times my sweety but it is still there.
Decreasing the rendering distance doesn't seem to do much...
Same with BETTER_PERSPECTIVE.
Quote from: Vogtinator on October 02, 2016, 08:38:46 AM
Why?
So It happens less often ?
I admit i'm not quite sure what causes this to happen but you can see it only bleeds in the blue sky background...
Any idea for a workaround ?
You could try to make the cubes smaller and change the camera so that it makes everything look right again,
that way the coords don't get out of bounds that easily. A proper fix would be to adjust the chunk's coordinates
to the player's position, so that the player is always at (0/0/0) and the chunks change coordinates instead of
the player. This will cost some vertex recalculation time, but will avoid large coordinates reliably.
(https://gameblabla.nl/img/crafti_dc_scr2.png)
I have made a basic port of Crafti for the Sega Dreamcast !
Like the GCW0 and nspire, it is still entirely software rendered but this DC port does not use SDL. (instead it just talks to vram_s)
The Dreamcast only has 16Mb of RAM, at first i encountered memory corruption on the images but i was able to reduce it so it is not noticeable.
Link (with source) :
https://gameblabla.nl/files/crafti-dreamcast.zip (https://gameblabla.nl/files/crafti-dreamcast.zip)
I should really make an abstraction to nGL/crafti so i don't have to make a specific fork or ifdef everything.
I wonder if it's easy to run homebrew on a DC because I got that console and I would definitively like to give this a try. (assuming this is finished and fully working, of course)
Quote from: DJ Omnimaga on January 20, 2017, 06:25:34 AM
I wonder if it's easy to run homebrew on a DC because I got that console and I would definitively like to give this a try. (assuming this is finished and fully working, of course)
You're kidding right ? This thing has no protection against unlicensed software.
It's the reason why games like Sturmwind are possible.
Only some late US Sega Dreamcast are unable to play homebrew games on CD. (and the Sakura Taisen ones)
If you want to give it a try, burn it with DiscJuggler, Alcohol 120% or ImgBurn with the discjuggler dll.
Crafti for the Dreamcast is catching fire, it seems, it's newsed by almost every dreamcast fan website ... :P
http://www.thedreamcastjunkyard.co.uk/2017/01/crafti-homebrew-minecraft-clone-for.html (http://www.thedreamcastjunkyard.co.uk/2017/01/crafti-homebrew-minecraft-clone-for.html)
http://www.dcemu.co.uk/vbulletin/threads/1158397-Crafti-A-Homebrew-Minecraft-Clone-For-Dreamcast-Released (http://www.dcemu.co.uk/vbulletin/threads/1158397-Crafti-A-Homebrew-Minecraft-Clone-For-Dreamcast-Released)
http://www.dreamcast.es/news.php?readmore=810 (http://www.dreamcast.es/news.php?readmore=810)
Tom from the Dreamcast Junkward made a quick video about it :
https://www.youtube.com/watch?v=IdX4Z4GK_8k (https://www.youtube.com/watch?v=IdX4Z4GK_8k)
This makes me feel a bit bad, as Vogtinator is not even mentioned in the news, even though he made the game.
I'm already getting threats because they want me to improve the perf of the DC port, not even my GCW0 port got this kind of reception.
I am asking, because over a decade ago I remember that they seemed to have serious difficulties trying to copy Dreamcast discs. While homebrew has been possible for ages, I was worried that there were still various restrictions to circumvent and that for homebrew I needed to mod my console or something unless the homebrew content came on an actual Dreamcast disc medium. I'll have to check how recent my console is
ALso it's nice they made a video. Shame that some people were negative about this port, though.
QuoteI have made a basic port of Crafti for the Sega Dreamcast !
Like the GCW0 and nspire, it is still entirely software rendered but this DC port does not use SDL. (instead it just talks to vram_s)
QuoteCrafti for the Dreamcast is catching fire, it seems, it's newsed by almost every dreamcast fan website ... :P
Good job!
QuoteThe Dreamcast only has 16Mb of RAM, at first i encountered memory corruption on the images but i was able to reduce it so it is not noticeable.
Is that the reason for the lack of the overlay textures? (Does it actually have 16 Mb (=2 MB) or 16 MB? The classic Nspire has about 8 MiB free with OS 3.9)
QuoteThis makes me feel a bit bad, as Vogtinator is not even mentioned in the news, even though he made the game.
I'm already getting threats because they want me to improve the perf of the DC port, not even my GCW0 port got this kind of reception.
Hehe :P If you are able to improve the performance in a upstreamable way, please send patches!
There is certainly a lot of room left, but as I never did any software 3d rendering before nGL I implemented it the most KISS way.
For example, by using spans instead of a z-buffer, only the scanline segments that actually end up on the screen need to be drawn:
https://mikro.naprvyraz.sk/docs/Coding/1/S_BUFFER.TXT
Quote from the DCEmulation forum:
QuoteYou should draw arrays of triangles, instead of calling a function for every vertex (glBegin vs. glDrawArrays)
This is already done for the main geometry: https://github.com/Vogtinator/crafti/blob/master/chunk.cpp#L251
Quote from: Vogtinator on January 20, 2017, 08:04:03 AM
Good job!
Thanks :D
Quote from: Vogtinator on January 20, 2017, 08:04:03 AM
Is that the reason for the lack of the overlay textures? (Does it actually have 16 Mb (=2 MB) or 16 MB? The classic Nspire has about 8 MiB free with OS 3.9)
Yes, exactly. They were corrupted when i attempted to show them on the screen. Not sure why ?
And the Dreamcast has 16 MB, 16 Megaoctets, not 16 Megapower.
With only 8 Mib left, i doubt you can run crafti on it :P
QuoteHehe :P If you are able to improve the performance in a upstreamable way, please send patches!
There is certainly a lot of room left, but as I never did any software 3d rendering before nGL I implemented it the most KISS way.
For example, by using spans instead of a z-buffer, only the scanline segments that actually end up on the screen need to be drawn:
https://mikro.naprvyraz.sk/docs/Coding/1/S_BUFFER.TXT
Hmm, this looks interesting. I wonder for which MS-DOS games used this technique ?
Sadly, this is beyond me... especially since you seem to enjoy C++'s tentacles... ;D
I will look at uploading the framebuffer to a PVR texture instead
QuoteYes, exactly. They were corrupted when i attempted to show them on the screen. Not sure why ?
They're created during runtime. You could try to embed them into the RO-section by replacing the newTexture calls with hardcoded ones.
Quote from: gameblabla on January 20, 2017, 08:49:28 AM
Quote from: Vogtinator on January 20, 2017, 08:04:03 AM
Is that the reason for the lack of the overlay textures? (Does it actually have 16 Mb (=2 MB) or 16 MB? The classic Nspire has about 8 MiB free with OS 3.9)
I thouggt that OS 3.9 only left you with 2-3 MB?