This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - Vogtinator
Pages: 1 ... 27 28 [29] 30 31 ... 83
421
« on: June 11, 2014, 08:19:13 am »
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.
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.
422
« on: June 10, 2014, 05:41:29 pm »
Congrats Vogtinator for your work. Your repo looks quite good. It looks good, but apart from the SDK part nothing works  Just try to execute the generated ndless installer or resources, instant crash.. I just created a nspire_emu repo and made an initial commit. Also, with the latest mingw32-w64 version it seems to compile on linux, and boot1 executes successfully!
423
« on: June 10, 2014, 04:16:56 pm »
Getting the nspire_emu kernel to run on anything else than win32 is a PITA. Just so overly many calls to windows-specific functions for which there isn't a simple equivalent in linux. I tried it once to remove the GUI stuff and get it to compile, but it stopped at an undefined reference in assembler to a win32 call. That was too much for me at that time and now I think it's easier to just use mingw and wine on linux..
424
« on: June 10, 2014, 04:05:30 pm »
Just do a quick diff of the two source folders, there are no huge changes, really. I totally agree with you, the ndless repo is indeed a big mess. I tried to clean up some parts on my fork, but can't do anything as I can't really get nspire_emu to build under linux.. You might be able to fix this with your patches!
426
« on: June 07, 2014, 06:14:52 am »
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.
Just the comparator, nothing more. And I don't think you'd build really complex machinery on crafti.. Anyway, I'll post a "redstone manual" to show how it will work. If you're familiar with minecraft's redstone, this shouldn't be a problem, the differences are small and most minecraft redstone stuff will work directly. V.
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
I am, just vote for mobs in the poll at the top. But currently it seems you're lucky Vogtinator, you probably forgot my question:
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 ?
I answered it, directly below. It wouldn't make any sense NOT to use the BLOCK_DATA bits as that's basically their purpose. And it wouldn't solve the compatibility issues either.
427
« on: June 06, 2014, 08:59:23 am »
No, face-combining is always active, but I could make it optional (as well as lighting), but it's not really worth the hassle.
I mean, just for aesthethical purposes calculating multiple textures, giving each vertex a texture ptr, light computation etc. would be way to slow.
The startup time would approximately triple, if not more and the chunk geometry calculations would get slower as well, but they would cause a noticable slowdown in game, as each block change (door opened, block destroyed, redstone changed, water flows etc.) triggers a recalc of the chunk and possible the adjacent ones as well..
428
« on: June 06, 2014, 03:05:23 am »
Both! Both tested, but 3.6 not regularily. The only ndless functions I use are hwtype(), isKeyPressed and fopen/fread/fwrite/fclose.
Edit: I just reseted the votes, removed lighting (doesn't work together with face-combining) and added minecarts (why not?)
429
« on: June 06, 2014, 02:10:58 am »
I could allocate some more, but I thought (e)ndless redstone would work better and is less annoying. It wouldn't make it slower at all, but a second array redstone_state[SIZE][SIZE][SIZE] would make more sense and is also easier for backwards-compatibility. But I need neither of them, the most parts are already implemented  Edit: BLOCK_SIDE is 3 bits wide, but some blocks need some more bits and I'd like to have it as flexible as possible.
430
« on: June 05, 2014, 04:30:57 pm »
The BLOCK_WDATA type is used as block storage.
Each block can also have some additional data, e.g. the side a torch has been put on, the type of flower, orientation of a furnace, or in this case, the side a door has been put on. The 7th bit is now occupied by redstone (powering on/off).
BLOCK_SIDE is defined asenum BLOCK_SIDE {
BLOCK_FRONT=0,
BLOCK_BACK,
BLOCK_LEFT,
BLOCK_RIGHT,
BLOCK_TOP,
BLOCK_BOTTOM
};
431
« on: June 05, 2014, 02:40:19 pm »
They're not free for doors: Somewhere in crafti, there's the enum BLOCK_SIDE, which is used as the highest 8 bits of the door's BLOCK_WDATA.
432
« on: June 04, 2014, 10:04:56 am »
Which 8 free bits? Edit: First test of some basic redstone 
433
« on: June 03, 2014, 04:05:42 pm »
Does it matter where the bit is? In the BLOCK_DATA or BLOCK (number)?
434
« on: June 03, 2014, 02:45:12 pm »
I did a quick test:  This monstrosity can only be opened with the real bottom part..
435
« on: June 03, 2014, 01:56:58 pm »
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. 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.
Pages: 1 ... 27 28 [29] 30 31 ... 83
|
Show Posts