WHO CAN MAKE MINECRAFT JUST LIKE THE REAL ONE? the winner get's a follow,a yeah on all there posts that I see! (really i just want minecraft because i don't own it)

I don't think that's possible...

if this is possible,I'm pretty sure minecraft is

Then do it yourself.

It's kinda hard....I haven't programed any video games yet

Then learn.

I recommend you make a small world first. Maybe (X)16×(Y)16×(Z)16, or 16³. I'm a noob programmer with this language. But, if I had the basic understandings? It might be possible at a mediocre level.

It does sound pretty cool, and for an infinite map, we would NOT want the pixellated effect (raytracing) approach, since the view distance would need to be very far, so it would be faster to physically draw the polygons I have a bit of experience with this concept, but not enough to construct a minecraft like game Plus it would be hard to keep the map active (water physics, sand/gravel, etc...)

A major impediment to an "infinite" map will be that a program can't write to disk (SD Card) without asking permission for every write operation. In MineCraft, as you move into new territory, the world around you is generated. Then as you move out of it, changes are written back to disk.

Even at only 1 byte per block, 256 x 256 x 128 would require 8 MB, and that's just for the map. This would be no problem if you could freely read/write to the SD Card, but if you need to hold it all in RAM... you're already out of memory.

Thats a good point, ok, what if we made it smaller, say 64x64 thats 4 chunks and we only keep a height of 64 Now thats 0.26 megabytes But if each block is a value of 0-256, then we can store multiple blocks in one byte, an integer ending in % is 32 bit signed ...continued

so an integers max value is 2^31=2147483647 Which can store three 256 values Thats 0.0874 megabytes for a 64x64x64 map Which is reasonable

Sorry your math confuses me. One byte (8 bits) can store values in the range 0 - 255. If an integer's value range is -(2^31) ~ +(2^31) then 4 bytes (32 bits) are required to store one integer.

Oh I was wrong thats 16 chunks Thats a reasonable world! So memory is not an issue, but speed might be, and that one I cannot calculate

Oh I see, well memory still should not be an issue

SmileBASIC has around 8MB of accessible heap memory. IIRC only arrays and strings occupy the heap, the rest occupies the stack, which is 128KB. So there's your lot for memory. If you need to write data out of memory, you need not write to disk immediately. Each GRP page is effectively an extra 512KB memory page. You could store in that assuming you appropriately convert your data to 2-byte colors.

Key, please?

calc84 made it, when's your game comin' out? (Wanna play it SO BAD)

Yes, but he used raycasting rendering instead of a polygon 3D approach, and with rather small map sizes. Something this big wouldn't work tbh

you own a wiiu, just buy it on that instead. pocket edition is the same price as smilebasic. if your too poor; theres a boatload of bad clones on 3ds and wiiu for $5, all of which would run better than a fan port and get updated fairly often