I was working on a little library awhile ago called Pixler for the TI-83/84s. Pixler could be used to easily to certain basic 2D graphical things, like draw pixels, draw lines, and draw squares.

I'm now updating my Pixler library to Pixler3D.
Pixler3D will give you the ability to draw points in three dimensions. It will also have subroutines to draw planes and rectangular prisms.

Note that all of these 3D shapes are wireframe.
They're not filled in, because if you did that, it would just be all black.
Also, since I don't have the TI-84 Color, I haven't ported this to it yet. I will do so once I get it, though. And I plan to get one near the end of next month.

I know how to do rotations in most other languages, but with z80 Assembly, I'm sure to have trouble with rotations, so I might not release that part for awhile. I do plan on doing them, though. I'm only a high school student, so cut me some slack.

So far, though, I have a 3D cube working. It needs some more work and stuff.

When you define points, I made a subroutine called "DefinePoint" and "DefinePointISO". "DefinePoint" creates points with a sort of perspective 3D. By this, I simply mean that the greater the depth of the point, the more it bends towards the center of the screen. This gives an illusion of 3D, like you would see in most 3D games. If the depth increases, this also results in the shape appearing to grow smaller, as if it's getting farther away. "DefinePointISO" gives you isometric 3D. The greater the depth, the more the cube is translated up and to the left. It does not curve towards the center. This is 3D you would see in most isometric games, like RTS games.

Here is an example of rectangular prism:


Note that it does not flicker and runs much smoother on the actual calculator than the emulator that I recorded that GIF on.

Currently, creating a cube would be done like this:


Code:

Note that (0,0,0) is not the top-left corner of the screen, but the center of the screen.

Anyways, yeah. That's one thing I'm working on.
I'll post the ".inc" file once I get it all nice and generally working.
I'll also post it as an environment variable for Mimas in which you could include into your Mimas programs.

That's basically how it's going to work.

Very impressive!

Im a very interested in 3D engines, particularly on z80 calcs. I think this is a great start.

Do you have any plans to use this library for a project or game?

Wow, that's really cool! I hope you post more with it. Like tr1p asked, are you planning on making any games?

As a side note, which emulator are you using? Something like jsTIfied or Wabbitemu might suit your needs better.

Not in particular.
I had a couple ideas.

If you've seen my PC game I'm working on, I was thinking of something similar to that.
Or, if you've seen my RPG game for the TI-83/84, I might make another RPG like that. Accept this time, I would have a 3D dungeon rather than the simplistic 2D one depicted in that game.

I notice you ran that with the Asm( command, which suggests to me that you're using the _ILine command. Is that correct? I have found _ILine to be very slow; you might be better off with the several-times-faster fastline routine in Doors CS 7.

I was using the TI-83 Flash Debugger.
jsTIfied seems to run slow for me, but it's what I mostly use since I do most of my work on my Chromebook.
I guess since I speed up the GIF anyways, it doesn't matter.

I've never tried Wabbitemu, except for the DS Homebrew port.



I actually originally wrote my own line routine.
But it was glitchy at times and I so I switched to _ILine until I can fix it.

Amihart: jsTIfied will take screenshots that display at "realtime" speed, even if you're on a slow computer, so it will give us a pretty accurate view of how fast the program is. As its coder, I certainly recommend you check it out, and I've been making strides towards speeding it up.

Then I'd certainly recommend you give my fastline a try. Not to mention that things like iFastCopy are significantly faster than grbufcpy_v.

Kerm is correct, you should see a decent speed improvement by switching those routines over.

Oh, nice, I'll try that out.
Also, since you're working on jsTIfied, would you mind porting jsTIfied to a packaged desktop app via Chrome? Basically, through Chrome, you can take web-based applications and package them into desktop applications that run offline. It's designed to be pretty easy so I'm sure it wouldn't take too long.

I know that's sort of a strange request, but I would like to use jsTIfied offline. And packaging it would allow me to install it onto all of my computers and use it offline.

You can also put it on the Chrome Web Store so anyone can install it just by going to the page and clicking it.

I could also explain how you can do so if you are unfamiliar with it.

I've been meaning to request for someone who's working on this to do so.

I'm assuming the lack of response means "no".
Anyways, once I finish the library, I'll update it for Doors CS for optimization.

I'm also changing some things.
Now, instead of storing everything in labels like above, you use registers. Such as, to draw a cube, now you do this:


Code:


BC holds the X and Y, DE holds the width and height, and HL holds the Z and depth.
I also made the "DefineCube" subroutine call on the "DisplayCube" subroutine automatically, and changed the label to "DrawCube". This way, you only have to call one of them and not two.

Here is the library so far if you want to download it and try it.
If you're using Mimas, add the file as a library in order for it to work.
If you're using any other z80 Assembly, just throw a "#include" in there somewhere.

Here is a demo of it so far:

Code:


If you don't know which calls take which inputs, just look at the comment at the top of the "pixler.inc" file. Or read it here:


Code:

Nice job!
Seems like there is tons of 3D-dev for the z80 these days

There is?
All I've seen is zDoom. I didn't know there was a lot of development already for something like this.

No, the lack of response just means I didn't get to respond to the topic. Thus far I've been hesitant to package jsTIfied in any way other than online, as it changes rapidly, and any packaged version would be quickly out of date. If you load the emulator in a tab and then go offline, it will continue to work properly. The only things that won't work are exporting files and taking screenshots.

Excellent, that seems like a logical change to me. Also, you can save a few byte by loading bc, hl, and de instead of b, c, h, l, d, and e:
Code:

I think it would be worth it, though. It shouldn't be too hard at all, and it will turn your emulator into one for the desktop, like Tilem.

How I solved that out-of-date problem for my game I'm developing is I wrote a couple "try...catch" statements.
Since package applications are nearly identical to the ones in the web browser, adding a couple "try...catch" statements could allow it to determine whether it's in the browser or the application, and execute code as so.

Such as this section:

Code:


In my game, when you press the "Create Dungeon", it first tries to create a new window. If it can't, that means it's probably being ran in the browser and isn't packaged, so it ditches that and just changes the browser window's location.

The idea isn't to port your code every single time. It's to change your code so that it works both ways.

Then, you don't have to worry about ever adjusting the code again to be packaged. Whether you run the file on the web server or as a packaged app, both ways it will run properly without ever having to port it again. Just, as you upload the new files to Cemetech, you also zip the files and upload the package as well.



Yeah, but I close tabs a lot. It's more convenient to load up something else.



Interesting, never thought of that.

Really? Didn't know, glad to hear it! So we should have a 3D Minecraft clone soon (which is possible).

Also, Amihart, your 3D program here looks excellent. Even if the screenshot is like nothing I've ever seen before, and is somehow reminiscent of an old TV.

Are you referring to the blue lines and flickering?
That's from the emulator. Not really my fault. :I



Because of all the people making 3D libraries, I've decided to turn mine into a different direction. Rather than being a full 3D library, it's going to be simplistic, but fast, and serve a specific purpose. Since most 3D engines people are making are probably going to have a ton of features that will slow it down, this engine is going to have specific features and be very fast.

I'm going to write easy subroutines for sprites, camera, and collision, so people can use the library to create 3D side-scrolling platformers. These are sometimes called "2.5D" platformers. I'm not going to bother with things that will slow it down, such as rotations (in which requires trigonometric functions), or "filling in" the faces of the blocks, or making ones behind others not show up.

For sprites, I'm writing three ways to draw sprites:

DrawSprite3D
DrawSprite
DrawSpriteFast

These are listed from slowest to fastest.
DrawSprite3D draws a 2D sprite in, you guessed it, 3D.
It's the same as DrawSprite, but increasing the depth makes it appear as if it's farther out.
DrawSprite simply draws a 2D sprite.
DrawSpriteFast draws a sprite very fast, but the sprite must have a width of 8 and can only move left and right in increments of 8.

Here's an example of DrawSprite:

Code:


For DrawSprite and DrawSprite3D, you define sprites like that.
"0" is an off pixel, "1" is an on pixel, "2" goes to the next line, and "3" means it's the end of the sprite.

DrawSpriteFast works like this:


Code:


DrawSpriteFast is zero-terminated.

For the camera, I'm just adding a pretty simple routine:


Code:


Basically, DefineCamera just takes and X, Y, and Z (bc and a) and stores it in memory for later.
When you draw a point onto the screen, the points location is adjusted based on the camera.
So, if you move the camera forwards, everything else will go backwards. If you move it left, everything else will go right.

Finally, I'm adding CheckCollision.
This will work like so:


Code:


"CheckCollision" will check if two objects are colliding, and set the Z flag if true, and reset it if false.