Current Progress

[elfprince13]

indeed, you've certainly been putting a lot of effort into this project.

[Iambian]

A very small update. It fixes a lot of the bugs that happened with the previous update (which was never guaranteed to work). Added experimental support for the xLIB tilemapper, though 16*16 mode remains unimplemented. The code for that was never tested, so it shouldn't be used unless you're willing to crash your calculator.

Anyway, this is the update.
------
EDIT: I've attached another release that addresses a couple more bugs, but I did not think it warranted an additional post, so I attached it in addition to this post. Most notable was the bug in xLIB's Execute Archived Program command. I'm still working on the sprite routine and the tilemap routine, but at least I know I'm getting somewhere. The demo program that luby gave me hasn't crashed yet, so I *think* I'm in good shape.
------
EDIT2: I've updated the application again with a very minor update, but it's not really worth downloading just yet. I'm just putting it up here because I'm sorta paranoid about the state of my development environment.
Anyway. The state of the build is as follows: the sprite routine has been tested to function correctly with the overwrite logic only. The other logics are *assumed* to work. The problem with it is that the sprite is said to be limited to 64*64, but I'm not sure whether or not this is the routine itself or if it's just documentation.
The real reason why you shouldn't download this version is because the tilemapper routine has been re-enabled, but it's BUGGED. It crashed the emulator. Why do I still have it enabled for a release? Because of the aforementioned reason, and possibly on the off chance that someone knowledgeable about assembler might be able to look at the code of the tilemapper in its current condition and state what's wrong with it just by looking at it.
... Well. I can dream, right?
Oh, and I still forgot about the AINSTALL program. I'll get to it. Eventually.

[DJ Omnimaga]

Nice, I will try this. Sorry I am kinda out of the loop lately so I missed the previous update

What I will do is install Metroid II on the emulator, but instead of installing xLIB I will install Celtic III

[vuurrobin]

[Iambian]

I've found more issues relating to the most recent post, as indicated by vuurobin (thank you SO MUCH for detecting this).

The sprite routine *assumed* an aligned mode, which was incorrect. To fix this and hopefully enable sprite flipping, I'm going to go a very lazy route and hack the routine to use IonLargeSprite to display the material. I just don't feel like writing my own routine if I find that someone else's routine can do the job for me.

Hooray for ION :)

In addition to the sprite routine, I've purposely disabled sprite flipping to determine if the main sprite drawing routine works. This'll be fixed as soon as I can get some decent results.

As far as the tilemapper goes, I feel embarrassed to say, but I never actually linked the jump table to the mapper, so nothing would result if I had accidentally executed the command while it was a WIP. In the build on my computer, I fixed this "error" and I plan on testing the tilemapper as soon as I can verify the sprite routine's integrity.

I seriously wonder how this'll work.
--------
As far as bad signatures go, I *am* using wabbitsign... so...
--------
EDIT: Now that I'm looking into sprite clipping, I figure I'm going to change the routine that converts floating point numbers into binary. The change is to allow processing of the sign of the input number so that routines that can take in negative numbers can process them as such (i.e. clipped sprite routines)
--------
EDIT2: I'm making progress on figuring out exactly how this sprite routine works. It's taking a while since the routine this guy made was coded on a level far higher than what I'm capable (at the moment). I think I've got the overwrite logic down, but I'll certainly need to figure out how to do the other logic in order to get it working for purposes slightly beyond its original.

The tilemapper in my build has *finally* been linked to the tilemapping routine instead of a predefined exit point, but I disabled it so I can work out the sprite routine.
--------
EDIT3: I've finally made the "overwrite" logic of the sprite routine to work. You might not think that's a big deal, but it certainly is, since the sprite routine works on a two-step basis. A simple LD would wipe out half of the results, which was what's happening in the earlier build. Glad I got that sorted out. Now I can go ahead and switch on the tilemapper to see what's wrong with the routine. (I hadn't tried it yet, but I'll wager money it won't work the first time)
--------
EDIT4: I've been working on getting the tilemapper to work. I've got it to correctly buffer the material prior to drawing the tiles on the screen. I've fixed and improved the tilemap buffer routine so that the tilemap (but not the tiles) are vertically aligned and that some of the math responsible for tracking the tiles are offloaded to parts of the routine that can be paged out. In all, I've got a solid platform that I can use to get the thing working. Now, if only I could actually get the routine that DRAWS the tilemap to work...,

[Iambian]

The update in this post addresses some of the issues regarding the sprite and the tile mapping routines. I am proud to say that the Celtic III application can now correctly render the demo package (as-is) that xLIB came with.

The 16*16 tile map still hasn't been tested, but it *should* work. I haven't implemented sprite flipping just yet, and I still haven't gotten around the 64*64 sprite size limit yet (if it exists).

But it does render the demo correctly :)

On another note, I've included the AINSTALL program in the folder "moreinfo". If you have the same development environment as I do (the TASM folder in the same directory as the _C3 folder (contains Celtic III files), then you can double-click the batch files to rebuild. For the typical user, however, just extracting the .8xk and .8xp files will work just fine.

As always, if there are any bugs, let me know. I've only tested this thing once, and it seemed to work alright. Speed comparisons will also be appreciated.

EDIT: Alright. I've noticed a few bugs already. I've moved on to testing using actual games today. At the moment, it's currently failing at rendering XXR. Expect an update as soon as I can resolve issues revolving around the game thing.

EDIT2: I've resolved the image problem with the build on my compuater, but no update yet. Reason being is that I'm going to now look for ways to get rid of the 64*64 limit for the sprite routine, since that's mucking up the rest of the game. Other than that, it should be pretty good.

EDIT3: Okay. I think the sprite routine's limit being 64*64 is mostly for documented purposes only. I guess the real problem in attempting exceeding 64*64 is when you want to CLIP a sprite bigger than that and further off screen than that. Reason I say this is because I've gotten XXR to work for the most part. I just need to patch the screen scroll routines to not preclear or something like that.
Also... I think I might just patch over the attachment on this post if nobody posts first since I think I released this version of Celtic III a bit too early. I'll see once I can get XXR correctly working.
------------
EDIT 4: The attachment has been patched over with another release. It will have the same name as the previous attachment, since I didn't do a whole lot with it. Except make it work
As far as I can tell, XXR now correctly plays with Celtic III instead of xLIB. Might as well call it CCR at this point
Now, all I need to do is test the 16*16 tile mapper and get the sprite flipping routine to work. Other than that, xLIB compatibility, for all intents and purposes, is a success.

EDIT 5: I've been alerted to problems relating to the drawshape command. I'll be up and about fixing it. I'll also be optimizing the sprite routine a bit so I can hope to get it up to speed.

[Demon]

Yay!

[elfprince13]

congratulations!

[Iambian]

No releases, but I will tell about the current state of development.

I've reworked the sprite routine a small bit so that its faster and there's less stuff to load to RAM. This was due to in part by me figuring out which parts needed to stay in Flash and what part needed to go to RAM, and reworking parts of the routine so that it's not only faster (sorta), but there's even less to copy to RAM because of it.

When I talked to tr1p1ea about the tilemapper, what I gathered from it was the following: My tilemapper is faster. Evidence shows a slight improvement when I timed the demo program that comes with xLIB, though I seriously think the bottleneck in this instance would be the sprite routine. If I can get that out of the way, I might be able to get it working even faster.

On another note, I fixed the problem revolving around the incorrect box being displayed. The problem was a small piece of code (one instruction) that was leftover after I changed what was needed to make the command run more reliably.

I still haven't tested out the 16*16 tilemapper yet, so would someone please provide a demo that can at least test that capability. DJ_Omnimaga, I know you have one of those.

The line drawing routine seems to be perpetually bugged. I'm going to see if I can figure out that mess before I go crazy.

Other than that, it just keeps getting better. All the time.

[Liazon]

coolness!

is this still under a page cuz that's pretty amazing

[Iambian]

The entire application *must* remain as a single-page application. Otherwise, there'd be no difference between installing the older Celtic III and xLIB at the same time and this new version of Celtic III. The main complaint was memory, and I'm addressing that by cramming these features into Celtic III as a single one-page package.

As for how I was able to fit all this into a single page, it's pretty evident if you were to read the source. Most of these features don't take up very much memory, especially if coded "properly".

And as for updates with Celtic III itself, there's no downloads yet. Instead, I've got more news. I intend on accelerating the way Celtic III looks up files by replacing the romcall "_ChkFindSym" with a custom-built routine. It should accelerate lookup since there's no romcall BS to deal with. By how much it speeds up, I don't know, since I haven't seen how efficiently (or inefficiently) the TI-OS looks up variables. Application size shouldn't bloat up by more than 200-300 bytes. I still have 2.5K left...

EDIT: I also plan on accelerating the RecallPic routines as that has proved to slow down XXR enough to cause a complaint. Either this, or it's the sprite routine that's doing it, but in all, I plan on having two case scenarios where the image file is in RAM or in Flash but not crossing a page boundary and one where it is crossing a page boundary.

I may consider writing a utility that will detect page boundary issues with images in Flash and possibly correcting it by unarchiving and rearchiving it and checking if the problem has been resolved. I do not know if the TI-OS is smart enough to check whether or not the contents of the file (image) has been changed but it's worth a shot if it helps guarantee speed consistency.

[DJ Omnimaga]

Why is there still no Xbox emulation implemented yet? :(

j/k I am amazed how nice it ran xLIB xLIB Revolution. The only problem was the signifiant speed drop by 0.5 FPS, which is big considering only a few xLIB commands are executed in one loop (scrolling, sprites, recallpic) and it could make a huge difference with grayscale. Also when the pics were archived the last 8 rows of pixels didn't showed up properly during the horizontal line transition in the XXR game. Other than that the game ran fine

[vuurrobin]

I have a demo with the 16*16 tilemaps. you can scroll with the arrows and stop with [clear]. it doesn't test anything else tho.

[brandonw]

[Iambian]

As far as things slowing down, I have it set up such that it tests the address if it crosses the page boundaries each time the address is incremented.. Now that I'm thinking about it, I could probably split the routine so it only handles bytes from one page, flips page, then handle bytes from the next page if need be. The boundaries will be precalculated prior to actually running so there's no slowdown associated with repeatedly testing.

That might be a better solution.

vuurrobin: Thanks for the test routine! That'll help out a lot.

[calc84maniac]

You do have it so negative values will be treated as positive for the tiles, correct? I'm pretty sure that xLib did that.

[DarkerLine]

[Iambian]

[vuurrobin]

it stil gives me a bad signature error when I try to send it with a usb-miniusb cable, and when I try to send it with a serial-i/o cable on another computer it doesn't appear in my apps list. I don't have this problem with other apps. does anybody else has this problem?

the tilemapper draws the entire tilemap, even when you specefy to only draw a part. and the drawsprite still wont flip the sprite.

edit: 300 posts

[Iambian]

I really apologize for this. I've forgotten that I haven't implemented some stuff still. I've been all worked up on how *fast* it was running, as opposed to ensuring that it was running at all.

As for the bad signature, there's little I can do about it with the current development environment. I'm just going to have to download TI's Flash Debugger and hope that I can get it working in the fashion I want it to.

Thanks, vuurrobin, for pointing out that the tilemapper won't work as specified. I'm unsure why it does that, since I have a whole load of code that is supposed to handle only those parts. Perhaps it's just... meh.

I think it's because of the bounds checking because everyone's used to using endpoints x=12 and y=8 when it really should be x=11 and y=7. I'll have to fix it up sometime later since it causes crashes when things like that occur.

Thanks again for pointing this out. A fix will happen when I get free time (which, on the weekends, I don't have a whole lot of)