Oh. You'd think that they would've had some sort of relay device that expedites the screen drawing considering the disparity there. I personally figured there was a draw buffer that was accessed by bankswitching then pushed to the screen. I'm not an engineer yet, so I don't even know if that'd be the most efficient. That's too bad though, I'd hoped the problem was software side. To me it seems odd to run a 16-bit device with an 8-bit processor though.

Apart from the CE, no calculator of the TI-84+ line or lower has had memory mapping, which is pretty much what you just described. And even then, the rest of the hardware is simply ancient. There's only so much you can do with a 15MHz processor where even the fastest instruction requires 4 clock cycles to complete, and to trying to drive 75K 16-bit color pixels with that is just not going to work very well, even with memory-mapping.

And why 16-bit? TI wanted a color calculator to deal with some of their competition, and that's what they could come up with without radically changing the basics of how the calculator is programmed (since their OS still has to run with little modification).

Even though you don't need a supercomputer to do basic addition and multiplication, you still need some minimum specs to make the whole thing work. From what I understood, too many people complained about the CSE's slowness, and so TI responded some time later by releasing the CE, which ran significantly faster due to its use of an ez80 processor with having memory-mapped (almost) everything.

Do remember that these devices were never meant to be used to play games, and so were never built with that capability in mind. The fact that it's possible at all is a testament to the programming community as a whole. I find it nothing short of a miracle that TI-Boy will run with any kind of speed on the CSE.

-Why are the graphical drivers so sluggish for the colour screen as many have pointed out? Could they be replaced?

When we speak of "driver" in this context, we're really talking about the combination of hardware and firmware that sits somewhere between the calculator's CPU and the actual glass. More information about the screen found in the TI-84+CSE is found here . Replacing that sort of thing is out of the question. It's generally assumed that all our programs use custom software designed to interact as directly as possible with the screen. The LCD is just much too slow to do it any other way.

Or rather, it's not that the LCD itself is slow. It's actually quite fast (as there's no need to delay between in/out), but the problem stems from three facts:
(1) The screen is a 16-bit device while the calc's CPU is 8-bit, so any and all communications require two separate read/write cycles.
(2) Every pixel must be addressed individually in each write, as opposed to groups of 8 per write in the context of monochrome.
(3) Related to the first two, there's no hardware acceleration of any type, including memory-mapping, which is often taken for granted.

Trying to update just the screen area required for the Game Boy screen alone requires 1/29th of the total CPU's time, and that's not even considering any logic whatsoever, not even any actual update logic. It's the single greatest bottleneck on the TI-84+CSE with respect to writing any decent program, and everything has to be coded around it.

Instead of a matrix, you can use strings to store map and collision data. It's just a little extra math to convert an X and Y coordinate to something you can use to look up things in the string (usually: (Y*width)+X).

For more info, try looking here.

Updated shop mockup. Also finished a new font shown off here:

I feel that I must mention that (the more recent versions of) CaDan had a custom font routine that supported kerning , which would be perfect for what you're doing (unless your character set has more than 64). If you want, I could extract that routine and make it a standalone.

For the past week or two (or three???), I've been hammering out additional details about the inventory menu, along with rearranging pieces of the project so I'll have enough space on page 0 to put all of this and more.

Equipment now has additional properties, such as elemental resistances, weaknesses, and attack. The confirm prompt in the shop is being reused to show item details in the inventory menu, and that confirm prompt is being upgraded to show off this information.

The screenshot below is not fully representative of what the final interface will be like. The confirm prompt is supposed to be paged, but I haven't gotten that far yet, so for now it just shows equipment properties. In the future, you'll be able to push up/down to cycle through equipment information.



If you've noticed, weapons show an "ATTACK" string, while non-weapons show a "RESIST" string. This is because weapons are not allowed to have a resistance, and thus, have no need to show a RESIST alongside it. Likewise, armor/accessories are not allowed to have an attack affinity (not even shields) so they have no need to show an ATTACK.

Not shown: Some equipment, when used as an item in battle (Final Fantasy (1) style), can unleash spells for free. Unlike FF1, this will be listed on the 3rd page. Also, the game has eight affinities total, but only five are shown. It's up to the player to figure out what those are and what equipment has them, either via experimentation, or by reading the manual.

The original non-bresenham based algorithm produced this result:

The algorithm that I called this done with, reposted here for visual comparison:

The code from the post above (code below)

Code: [Select]

    ld b,1             ;use this to check if we bresenhammed
    ld hl,(_cam_acc)
    bit 7,h            ;sign check
    jr nz,_br_xfail    ;skip if acc less than zero
    ld a,(_cam_yx+0)   ;xpos
    ld c,a
    ld a,(_end_yx+0)
    cp c
    jr z,_br_xfail     ;skip if x1==x2
    ld a,(_cam_mover+0)
    add a,c
    ld (_cam_yx+0),a
    ld de,(_cam_dy)    ;negate this in the setup code
    inc b
    add hl,de
    inc b
    jr c,_br_yfail     ;skip if acc is non-negative.
_br_xfail:
    ld a,(_cam_yx+1)   ;ypos
    ld c,a
    ld a,(_end_yx+1)
    cp c
    jr z,_br_yfail     ;skip if y1==y2
    ld a,(_cam_mover+1)
    add a,c
    ld (_cam_yx+1),a
    ld de,(_cam_dx)
    add hl,de          ;acc+dx
    inc b
_br_yfail:
    ld (_cam_acc),hl
    dec b
    ret


Produced this result:


That wasn't exactly the results I was looking for, tho since I dropped that in, I might have messed up somewhere?

When I transcribed the BASIC program into assembly, I did it to the best of my knowledge. The additional check that I added to determine if the bresenhammer did something that cycle was not of paranoia, but of an actual bugfix when the loop never exited. The loop exits when it sees that (x1,y1)==(x2,y2). I saw that no matter how many times the thing ran, it never reached y1==y2 and the sign on the accumulator was wrong so that would never get checked, so I added code that would flip that sign  to force the routine to do *something* so the external coordinate check might eventually exit.

As for the positional values themselves, they're all 8-bit unsigned with the range 0-255 (7bit map + 1bit subtile), which is part of the reason why the accumulator, and delta x/y are kept as words instead of bytes.

----
And in other news, minor work was done to slightly re-arrange the shop's buy-confirm prompt to make buying consumable items more meaningful and provide slight consistency between equipment and consumable purchases in light of that change:

Thank you very much Xeda112358, that TI-BASIC code translated to assembly works great, though I did have to add in some extra logic that would prevent the routine from locking if the accumulator is the wrong sign for the final iteration (it just flips it if the routine did nothing that cycle).

The calling routine pretty much did exactly what you did in the BASIC code. The only thing I had to change was where the "ld (_cam_acc),hl" instruction was located.

The actual algorithm, tho. This is what I got:
res did_it_bresenhamming,(iy+stateflags)
 ld hl,(_cam_acc)
 bit 7,h  ;sign check
 jr nz,_br_xfail ;skip if acc less than zero
 ld a,(_cam_yx+0) ;xpos
 ld c,a
 ld a,(_end_yx+0)
 cp c
 jr z,_br_xfail  ;skip if x1==x2
 ld a,(_cam_mover+0)
 add a,c
 ld (_cam_yx+0),a
 ld de,(_cam_dy)
 or a
 sbc hl,de ;acc-dy
 set did_it_bresenhamming,(iy+stateflags)
_br_xfail:
 bit 7,h  ;sign check
 jr z,_br_yfail ;skip if acc is non-negative.
 ld a,(_cam_yx+1) ;ypos
 ld c,a
 ld a,(_end_yx+1)
 cp c
 jr z,_br_yfail ;skip if y1==y2
 ld a,(_cam_mover+1)
 add a,c
 ld (_cam_yx+1),a
 ld de,(_cam_dx)
 add hl,de ;acc+dx
 set did_it_bresenhamming,(iy+stateflags)
_br_yfail:
 bit did_it_bresenhamming,(iy+stateflags)
 jr nz,_br_nofail
 ld a,h
 xor $80  ;flip sign bit to force next iter to do something
 ld h,a
 ld (_cam_acc),hl
; call _cmp_cur_to_end_pos
 jr nz,_iterateBresenham  ;reiterate bresenhammer.
_br_nofail:
 ld (_cam_acc),hl
 ret
The end result: