Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - chickendude

Pages: 1 ... 35 36 [37] 38 39 ... 55
541
ASM / Re: RAM required for Jim E's fast tilemapper
« on: November 20, 2012, 11:01:30 am »
Ahhh that makes much more sense. That's clever :)

542
Introduce Yourself! / Re: Dzień dobry
« on: November 20, 2012, 10:55:55 am »
I don't think z80 asm is that hard, either, and it's loads of fun ;) Anyway, dzień dobry and witamy :)

543
ASM / Re: RAM required for Jim E's fast tilemapper
« on: November 20, 2012, 05:54:31 am »
tr1p1ea, how do you get a LUT of 2kb? If each tile is 8x8, 256*8=2048, and that's just the basic tiles, non-rotated... CrASH's mapper did something similar, too, i believe (prerotating the tileset).

544
ASM / Re: Calculating angles?
« on: November 20, 2012, 05:35:23 am »
Tr1p1ea: It aims towards a set of coordinates. For the boomerang, going out it gets an initial angle/velocity aimed at the player and follows a straight path until it hits the edge of the screen. Then it comes back, this time updating the angle every frame based on the boss's position so that it returns to the boss. This is one of the more boring bosses :P

545
News / Re: A new z80 calc... in color?
« on: November 15, 2012, 01:20:40 am »
But now TilEm2 is awesome and it's all i ever use anymore ;) The real question though is when will the first 84+C emulator come out?

546
News / Re: TI-84 Plus C: new photos reveal more than 3MB archive space
« on: November 14, 2012, 02:25:12 pm »
No, what happens is that code is copied to 8000h, then it is called. When you use "call", the the program counter is pushed to the stack. The code that got copied to 8000h is:
Code: [Select]
pop hl
push hl
ret
(which, as discussed elsewhere can be optimised :P )
Basically, HL now has the address that the original routine called it from. Then, we use bcall(_DispHL). If that bcall() has been changed or destroyed in some way, then there will be issues.

EDIT: The purpose of the code is to figure out where programs are run from. Once we know that, we can figure out how broken compatibility will be and start fixing our programs now, before the release.
Err... i think we're talking about different programs. I was looking at "prgmPAGEDUMP", oops :P

547
News / Re: TI-84 Plus C: new photos reveal more than 3MB archive space
« on: November 14, 2012, 12:09:12 pm »
It could also mean programs aren't run from $9D95 and the labels aren't being treated correctly, in particular the call(s) and the AppVar name. Or that the BCALL table has changed.

548
News / Re: TI-84 Plus C: new photos reveal more than 3MB archive space
« on: November 14, 2012, 12:23:16 am »
Shouldn't that be 0:Asm(prgmPAGEDUMP ? ;)

549
ASM / Re: RAM required for Jim E's fast tilemapper
« on: November 13, 2012, 12:15:16 pm »
Jim's mapper uses a buffer for the sides, right? (to scroll in from left/right) I assume that means you need gbuf + an extra 64 bytes (8x8) or 128 bytes (16x16). It's probably all contiguous though.

Btw, i found this:
http://web.archive.org/web/20061010131750/http://www.revsoft.org/phpBB2/viewtopic.php?t=423&postdays=0&postorder=asc&start=75

I don't know if that's how the final version was handled but it seems like animated tiles are redrawn every frame but everything else is left alone. I think redrawing the entire map every frame would give you a more even frame rate and would still leave you with a nice speed, but i dunno.

Btw, i also found this quote:
Quote from: Jim e
When I want to scroll my code calls certain functions like this depending on the number of pixels to move

1: Scroll_Left_1
2: Scroll_Left_1,Scroll_Left_1
3: Scroll_Left_4,Scroll_Right_1
4: Scroll_Left_4,
5: Scroll_Left_4,Scroll_Left_1
6: Scroll_Left_4,Scroll_Left_1,Scroll_Left_1
7: Shift_Bytes_Left,Scroll_Right_1

Any value greater than 8, I simply shift the bytes. Scrolling 4 bytes I make use of the RRD and RLD opcodes.

The data in the blank areas is then filled with an optimized tile drawer.
EDIT: Grammar

550
I think manually porting games won't be too difficult, though. Well, assuming the new larger/color LCD doesn't slow things down and the processor/LCD can still handle games at that speed.

551
Also, you have to keep in mind that there might not be a gbuf anymore. As others have mentioned, a gbuf might not even fit in RAM!

552
ASM / Re: RAM required for Jim E's fast tilemapper
« on: November 13, 2012, 08:41:44 am »
It's the tilemapper Jim e wrote, it's fast and can handle large jumps (from 1 pixel to... i dunno how many, maybe 255?). Hot_Dog, i was under the impression that it redrew the map every time, i dunno how else he would've done the parallax scrolling demo with all the animations. I've never actually used it and it's been ages since i looked at it, do you have a link to it somewhere?

553
I'm with Hot_Dog, i'm looking forward to finally having a nice z80 color platform to play with. I just hope that it will be able to handle fullscreen color graphics quickly enough to support decent games. Now that the screen won't be divided into groups of 8 pixels, just filling the screen is going to take much longer (or will at least need to execute a lot more instructions).

554
News / Re: 2012 Apocalypse TI-83+/TI-84+ Programming Contest
« on: November 13, 2012, 07:05:33 am »
Also, what place does a computer category have in an 83/4+ programming contest? :P

555
Ash: Phoenix / Re: Ash: Phoenix- Reboot
« on: November 12, 2012, 01:20:25 pm »
Hayleia, i think what you're talking about is clipping (having part of a sprite off-screen). Generally, Y clipping is pretty easy: if you want to draw to y position -3 you subtract 3 from the number of rows to draw and add 3 to the starting point of the sprite. It's quick and easy. X clipping is a bit more complicated, however, but still not so bad :) Axe doesn't have a clipped sprite routine?

EDIT: I've also seen TinyCraft II and it looks really beautiful. And i second squidgetx's request to know how you handle the chickens!

Pages: 1 ... 35 36 [37] 38 39 ... 55