Login [Register]
Don't have an account? Register now to chat, post, use our tools, and much more.
This is an archived, read-only copy of the United-TI subforum , including posts and topic from May 2003 to April 2012. If you would like to discuss any of the topics in this forum, you can visit Cemetech's Your Projects subforum. Some of these topics may also be directly-linked to active Cemetech topics. If you are a Cemetech member with a linked United-TI account, you can link United-TI topics here with your current Cemetech topics.

This forum is locked: you cannot post, reply to, or edit topics. Celtic III => Your Projects
United-TI Archives -> Celtic III
 
    » Goto page Previous  1, 2, 3, 4, 5, 6  Next
» View previous topic :: View next topic  
Author Message
elfprince13
Retired


Super Elite (Last Title)


Joined: 11 Apr 2005
Posts: 3500

Posted: 20 Mar 2008 07:50:18 pm    Post subject:

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


Advanced Member


Joined: 13 Mar 2004
Posts: 423

Posted: 31 Mar 2008 03:56:16 pm    Post subject:

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.


Last edited by Guest on 11 Apr 2008 12:03:51 am; edited 1 time in total
Back to top
DJ Omnimaga
http://i-lost-the-ga.me


Calc Guru


Joined: 14 Nov 2003
Posts: 1196

Posted: 31 Mar 2008 04:00:44 pm    Post subject:

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
Back to top
vuurrobin


Advanced Member


Joined: 09 Aug 2006
Posts: 428

Posted: 06 Apr 2008 03:46:28 pm    Post subject:

Quote:
I've attached another release that addresses a couple more bugs, but I did not think it warranted an additional post


new releases always deserves a new post Laughing , especially if somebody already posted in between.


anyway, when I try to send the app to my calc, ti connect gives an error bad signature. and from what I saw trying the app in pti, the drawsprite does work, but its flip function doesn't work and giving the x coordinate for placing it on the screen has some issues. the tilemapper doesn't crash, but it doesn't display anything either. sorry for not giving more info, but I don't like testing on a emulator, and since I can't send it to my calc...


I also notised that the ainstall program is missing.
Back to top
Iambian


Advanced Member


Joined: 13 Mar 2004
Posts: 423

Posted: 07 Apr 2008 01:22:05 pm    Post subject:

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...,


Last edited by Guest on 14 Apr 2008 10:30:39 pm; edited 1 time in total
Back to top
Iambian


Advanced Member


Joined: 13 Mar 2004
Posts: 423

Posted: 15 Apr 2008 02:14:56 pm    Post subject:

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 Smile
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 Razz
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.


Last edited by Guest on 15 Apr 2008 09:11:32 pm; edited 1 time in total
Back to top
Demon


Advanced Member


Joined: 17 Jun 2006
Posts: 369

Posted: 15 Apr 2008 07:57:01 pm    Post subject:

Yay!
Back to top
elfprince13
Retired


Super Elite (Last Title)


Joined: 11 Apr 2005
Posts: 3500

Posted: 15 Apr 2008 08:53:22 pm    Post subject:

congratulations!
Back to top
Iambian


Advanced Member


Joined: 13 Mar 2004
Posts: 423

Posted: 16 Apr 2008 01:48:27 pm    Post subject:

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.
Back to top
Liazon
title goes here


Bandwidth Hog


Joined: 01 Nov 2005
Posts: 2007

Posted: 16 Apr 2008 03:42:12 pm    Post subject:

coolness!

is this still under a page cuz that's pretty amazing
Back to top
Iambian


Advanced Member


Joined: 13 Mar 2004
Posts: 423

Posted: 16 Apr 2008 07:51:33 pm    Post subject:

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.


Last edited by Guest on 16 Apr 2008 08:09:53 pm; edited 1 time in total
Back to top
DJ Omnimaga
http://i-lost-the-ga.me


Calc Guru


Joined: 14 Nov 2003
Posts: 1196

Posted: 16 Apr 2008 10:08:55 pm    Post subject:

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
Back to top
vuurrobin


Advanced Member


Joined: 09 Aug 2006
Posts: 428

Posted: 17 Apr 2008 08:15:15 am    Post subject:

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.
Back to top
brandonw


Advanced Member


Joined: 12 Jan 2007
Posts: 455

Posted: 17 Apr 2008 09:29:01 am    Post subject:

Iambian wrote:
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.
[post="122519"]<{POST_SNAPBACK}>[/post]


This feels very sketchy. It's hit-or-miss on whether unarchiving and rearchiving will help, and even still, you're taking a chance on garbage collecting, which you can work around by hooks, but still. That's unnecessary wear and tear on the Flash.

I find it kind of odd that crossing a page boundary would significantly slow things down. Reading a byte from the next page just adds "bit 7,h \ jr nz,$F \ res 7,h \ set 6,h \ inc b \ $$:" if B were the page and HL were the address.

Of course, you could just write an improved garbage collector, but...eek.

I'm also not sure what you mean by whether the OS is smart enough to see whether the contents have been changed. The OS never cares what the contents are, it would just update the VAT pointer to wherever it has been moved to.


Last edited by Guest on 17 Apr 2008 09:30:32 am; edited 1 time in total
Back to top
Iambian


Advanced Member


Joined: 13 Mar 2004
Posts: 423

Posted: 17 Apr 2008 11:45:25 am    Post subject:

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.
Back to top
calc84maniac


Elite


Joined: 22 Jan 2007
Posts: 770

Posted: 17 Apr 2008 11:48:37 am    Post subject:

You do have it so negative values will be treated as positive for the tiles, correct? I'm pretty sure that xLib did that.
Back to top
DarkerLine
ceci n'est pas une |


Super Elite (Last Title)


Joined: 04 Nov 2003
Posts: 8328

Posted: 17 Apr 2008 12:30:00 pm    Post subject:

calc84maniac wrote:
You do have it so negative values will be treated as positive for the tiles, correct? I'm pretty sure that xLib did that.
[post="122552"]<{POST_SNAPBACK}>[/post]
That could be an artifact of the number-conversion routine (_ConvOP1) which, in all likelihood, simply ignores negative signs. After all, that makes more sense than checking for the sign just to throw an error if the sign is negative.

Last edited by Guest on 17 Apr 2008 12:30:59 pm; edited 1 time in total
Back to top
Iambian


Advanced Member


Joined: 13 Mar 2004
Posts: 423

Posted: 17 Apr 2008 12:36:01 pm    Post subject:

calc84maniac wrote:
You do have it so negative values will be treated as positive for the tiles, correct? I'm pretty sure that xLib did that.
[post="122552"]<{POST_SNAPBACK}>[/post]

Eh... no. They're treated as (65536-abs(N)). I can probably have the routine detect this but that's not too high on my priorities since I can safely assume that no one would try a stunt like that. In addition, I recall having problems when I did try to use negative numbers in a demo program I wrote a while back. Something about a system error being triggered and strange stuff appearing on the screen (but no crash), so I don't think anyone else would be doing it.

EDIT: The 16*16 tile mode is definitely bugged. I'm working on solving the problem, but it's kicking my butt at the moment.

EDIT2: I've attached another version of the application. I've accelerated the recallpic routine using none of the methods involved. I've fixed the 16*16 tile mode and the sprite routine should have been sped up by a slight bit, though I'm not entirely sure if it's noticeable. The line drawing routine is more than likely still bugged and I don't think I've addressed any defects associated with the recallpic routine so...

Please tell me what you think and what bugs you find.


Last edited by Guest on 17 Apr 2008 02:26:19 pm; edited 1 time in total
Back to top
vuurrobin


Advanced Member


Joined: 09 Aug 2006
Posts: 428

Posted: 18 Apr 2008 07:02:50 pm    Post subject:

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 Laughing


Last edited by Guest on 18 Apr 2008 07:04:17 pm; edited 1 time in total
Back to top
Iambian


Advanced Member


Joined: 13 Mar 2004
Posts: 423

Posted: 18 Apr 2008 11:27:04 pm    Post subject:

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)
Back to top
Display posts from previous:   
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
    » Goto page Previous  1, 2, 3, 4, 5, 6  Next
» View previous topic :: View next topic  
Page 4 of 6 » All times are GMT - 5 Hours

 

Advertisement