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 - ben_g
16
« on: May 03, 2015, 10:51:19 am »
The ports of the calculator are meant for data. They can only supply a small current. It may be just enough to control a relay, but it's best to put transistors between them, just to be sure (or control the motors directly using transistors, if your transistors are powerful enough).
And in any way, don't forget to put a discharge diode on the relay (put a diode in parallel over the coil of the relay in the direction that it blocks incoming power).
17
« on: May 01, 2015, 04:52:54 pm »
Oh look, a video!
If I had that thing in my room, I'd leave it running all the time, because seeing all those things moving looks really cool. Is that thing reliable? Because with so many moving parts, there's really a lot that can go wrong. I really hope you can keep it fully functional for a long period.
18
« on: April 29, 2015, 12:00:37 pm »
I have no idea if this applies to the nspire, but do you use a dumped ROM or a generated one? Iirc axe in it's current version avoids using undocumented instructions to keep it compatible with the monochrome nspires. But at least on computer emulators, it doesn't work well with a generated ROM.
19
« on: April 28, 2015, 04:47:11 pm »
:O
That thing is huge!
20
« on: April 27, 2015, 04:08:04 pm »
... Another thing, this can actually draw textures right?
I don't think it can. * ben_g should really blow the dust of his calc projects and finally mod that in
21
« on: April 27, 2015, 01:14:48 pm »
What's the problem you're having? It's hard to look for problems when you don't know what's happening.
22
« on: April 26, 2015, 03:23:17 pm »
Simple: instead of using GBD's, you use a normal variable, for example L. Then, at the start, you just to GBD1->L, and then when switching levels, you simply store the next gdb in the variable (for example GDB3->L)
23
« on: April 26, 2015, 09:08:14 am »
If getKey(1) and (sub(GT,X,Y+8)=0 or sub(GT,X,Y+8)=3)
...
Axe doesn't know the order of operations, so it evaluates everything from left to right, meaning that it will check if key 1 is pressed and (sub(GT,X,Y+8)=0 or sub(GT,X,Y+8)) equals 3. Try this instead: If getKey(1) and (sub(GT,X,Y+8)=0 or (sub(GT,X,Y+8)=3))
Note the extra parentheses around the last conditional.
24
« on: April 25, 2015, 06:23:13 pm »
I think you made a mistake here:{r2/8+12+(r1/8)+GBD1}I think that should be:{r2/8*12+(r1/8)+GBD1}(* instead of +)
EDIT: I just noticed that you move your player 8 pixels (or 1 tile) at a time. If you plan on doing that in the final version of your game, then I'd reccomend using tile coordinates instead of pixel coordinates. Now, the X and Y are the location at which the sprite should be drawn, and you have to multiply/divide with 8 troughout your whole program, but if you set the X and Y to the tile the player is on, then you'd only have to multiply by 8 when you draw the sprite.
This could save you a few bytes and a few cycles, and it makes everything a little bit clearer, though you won't be able to place your player halfway on a tile.
25
« on: April 25, 2015, 04:29:07 pm »
GLib, as odelore has already pointed too is a good one. There's also JH3D, but I haven't used this one personally, so I don't know what's possible with it. But, before you start, you should know that 3D on a calculator is still pretty much experimental. You'll only be able to draw simple shapes with a few lines with most engines, and some basic features like Z-buffering are often missing due to hardware limitations. And while rendering environements in 3D is possible, it's deffinately not as straightforward as simply making a level and calling a function to render it. You constantly have to find workarounds for almost everything, but off course, that's part of the fun  . I'm not trying to scare you, and I'd love to see more finished 3D games for the z80 calcs, but a 3D calculator project nothing that you should start unprepared. If you're still interested, then my advice would be to first do some test with a computer 3D engine (if you have no experience with them) to get familiar with the 3D math. If, after all this, you're still interested in taking on this project, then I wish you good luck and lots of fun  And if you run into troubles, don't hesitate to ask. There are multiple people here that have also given calculator 3D a try.
26
« on: April 20, 2015, 03:18:30 pm »
Someone on our team made some concept art of our current main project:  I think he drew it really well, so I thought I should share it. The project is an fps with horror and puzzle aspects, called 'The Lost Survivors'.
27
« on: April 19, 2015, 03:20:48 pm »
...It actually uses just the same save file as GrayLib, to encourage people to make grayscale settings per-calculator!
Great idea!
28
« on: April 11, 2015, 12:48:56 pm »
This sounds like a really diffucult project, but if it works, it would be awesome.
A suggestion if you have extra time at the end of this project would be a better mathPrint. I know the OS you're trying to optimize doesn't have it, so it might be hard to do, but I've seen calculators that are much simpler than the 84+ that had something similar to MathPrint that was far better and also faster than what the 84+ MP OSes have.
And better floating points would be cool too (I heard that if you use real binary floats, you can get both better performance and better accuraccy), but that would probably require a rewrite of almost the entire core of the OS (and also of huge parts of the BASIC interpreter).
BTW: are you mainly trying to increase performance, or could it be possible to also free up an extra page or two?
29
« on: April 06, 2015, 04:53:06 pm »
Bitmap textures are indeed very expensive to draw; even if I could get it to work, the engine already requires significant CPU power for the other stages of the rendering pipelines (rotating, projecting, 2D clipping, 3D clipping, etc). However, my engine is geared towards drawing/clipping lines and polygons, so the "textures" are not bitmaps, but a series of 3D lines and polygons that are "attached" to the wall (i.e. vector graphics). Suppose that I wanted to draw "Hello" on a wall. Instead of drawing the pixels that make up the 'H', I could instead store the 3D lines that make it. Then, it's easy and fast to draw because it's just a bunch of lines instead of having to do perspective-correct texture mapping. While this does limit the type of "textures" you can create, I think it's better than having all blank walls.
For a calculator, you shouldn't have to do perspective corrected texture mapping. You get almost as good results from affine texture mapping if the textures aren't stretched too much. And calculation-wise, textured triangles were about 2-3 times as heavy as the solid ones (Though I have to admit: both the solid and the textured triangle drawing routines were terribly optimized). So, depending on the complexity of the textures you use and how efficiently your engine does the 3D to 2D conversion, a bitmap could sometimes be faster.
30
« on: April 06, 2015, 07:26:16 am »
Textures are always a big deal with calculator 3D engines, because they require a loooot of processing power. As far as I know, the only engine that's fast enough to provide textured polygons is nGL on the TI-Nspire because this calc has a lot of processing power actually.
* Ben_g points to   If you have problems handling bigger levels, then it's ofthen best to divide them into a few sections. Then for every one of those sections, you have a small list which indicates which other sections are visible from that section. Then you only render the section you're in and the sections visible from there. You'll have to put a bit more work in your levels to do this, but it makes it possible to have much bigger levels with minor overhead. I've used this trick a few times in some unreleased test projects of mine, to render environements that are too big for the 84+ to render, like entire race tracks.
|
Show Posts