It runs at 6 mhz. I'd like to keep compatibility with the 83+BE. It's actually slowed down unless you run, which just removes the delay. Full speed gives insane scrolling speed.
To do :
-Chunk handling
-Scripting engine
-NPC handling on the map (rendering + collision)
-Battle engine (I have some pretty neat ideas including a research system for spells instead of learning on level-up)

Hosting the roms directly like that is illegal, so ...
But yeah, ways to get ROMS are to find them through the mysterious ways of the Internet ... ()  or to dump it from your calc.

Or to make one with Wabbit, even though it's inferior quality.

Not a 8xu file but an actual ROM dump or a Wabbit made ROM. It's actually the entire flash.

Hi !
I've been working on a smooth scrolling grayscale tile mapper for an RPG.
Don't ask info about the game, I'm still trying to find a good storyline.

Features :
-8*8 3 level grayscale tiles
-Pokémon style scrolling
-Hayleia's interrupt gray method for really smooth gray
-Couple ASM routines for fast horizontal scrolling
-The code is as optimized as I can alone. It's very fast and fits in 2.4k (speed optimized).
-8 frames walking animation + 4 directions for the character implemented but not visible since I put the same sprite 32 times.

To try it, send both progs to your calc, run MAP to create the data appvars then ATILE.
The source is in the SRC dir (the assembly routines are in THEGAME.z80 and compiled as an Axiom). Never mind the empty makefile. I was about to set it up but I didn't.

The gray actually looks better on calc. You may want to calibrate it : change the value of Z under Lbl INTI).
Hold Alpha to run.

To post source code, you can use SourceCoder or TokenIDE, which are on-computer TI-Basic/Axe editors (they're respectively web and app based).
And for your problem, you can simply check whether or not the sprite is on screen, and then draw it at the proper position if it is. That's what Runer meant by "initial major clipping" I think.

I think there's some boot code stuff but IDK how to use it. :s

I'm scrolling a bit faster than the interrupt. Syncing it doesn't fix it so I think it's the calibration because 3 level looks perfect at the same speed.

You could call a piece of code each time the screen is drawn, but you have to keep your code short to avoid interrupting on itself.

Actually you can encapsulate your interrupt with FnOff and FnOn to avoid that. Then put what you want in. The main reason why an interrupt should be short is speed. The longer it is, the more lag you create in your main prog.

Also I've compared 3 vs 4 levels and 3 looks clean when scrolling while 4 looks really blurry. Maybe it's because I can't calibrate it correctly.

recently

I don't think october is recent.
Also to make the screen gray you should use ClrDraw:Fill(L3,768,255) which is much faster since you don't do any calculation. And it's much easier to read.
This could work for RPGs too but it will force you to have slow scrolling since you're using the same loop for both. Even if this method is nice in some cases (like a pic viewer or a chess game as you pointed out) since it's a bit easier to set up, interrupts are the way to go when possible since it can actually make stuff more optimized sometimes.