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 - Xeda112358

Pages: 1 ... 93 94 [95] 96 97 ... 317
1411
Other Calc-Related Projects and Ideas / Re: OmniRPG - Sprites
« on: December 08, 2012, 07:45:50 am »
Well, I've changed my mind after talking to chickendude and seeing some screenies from zer project. I'm definitely for monochrome 16x16, but the sprites are going to be rather large and the tilemaps. Why?

This means that sprites will need two layers for masking, and with how I am thinking of collision detection, another layer will probably be needed, meaning each tile will be 96 bytes 0.0

If we can figure out how to keep it in archive, though, that won't be a problem at all.

1412
TI Z80 / Re: PROGRAM: Polynomial Math Utility
« on: December 08, 2012, 07:34:06 am »
Wow, that would actually be cool if you managed to make a way to parse a function like that. It would be rather tough, though XD

1413
TI Z80 / Re: PROGRAM: Polynomial Math Utility
« on: December 07, 2012, 04:57:07 pm »
Basically, for division, it would be the same as 24-bit division by a 24-bit number (think about it, 11.8/22.3 = 118/223). You would need to adjust the algorithm a little to bring in the extra 8 bits of precision, though. For multiplication, you would do the same thing as 24-bit multiplication , but remember that the bottom 16 bits will be the decimal part and the upper 32 bits will be the integer part. If the upper 16 bits are not 0 or -1 (-1 is in case you have signed numbers), then there was an overflow, and if the lower 8 bits have bit 7 set, then you will need to round up the number (if you want rounding done). Addition and subtraction are also straightforward and is just like adding or subtracting 24-bit numbers.

Keep in mind that for division and multiplication, you will want to keep track of sign. I also think that there is a problem with how I described multiplication, but hopefully calc84maniac or Runer112 will be able to tell you how to do that properly.

1414
Portal X / Re: Portal X (Prelude) Bugs
« on: December 07, 2012, 04:40:31 pm »
If he puts a roof over it, that will make the level super easy XD (I still haven't gotten past it o.o)

1415
TI Z80 / Re: PROGRAM: Polynomial Math Utility
« on: December 07, 2012, 04:28:14 pm »
Hmm, so it is going to support non-integers?

1416
TI Z80 / Re: PROGRAM: Polynomial Math Utility
« on: December 07, 2012, 04:13:15 pm »
The input is nice, though, and I am glad that you support the use of 2 and 3 :) I remember I wrote a synthetic division program a few years ago, but it only took list inputs.

1417
TI Z80 / Re: PROGRAM: Polynomial Math Utility
« on: December 07, 2012, 03:53:23 pm »
Hmm, division at least appears to be broken. For example, try X^4-1 divided by x-1. It should be x3+x2+x+1, but it outputs x3+x3+x+1.

1418
TI Z80 / Re: [2012 Apocalypse Contest] Battle 4000
« on: December 07, 2012, 12:25:59 pm »
Here is a quick little update. I started work on the blacksmith and I've programmed in 3 weapons. Currently, you can view the three weapons and see what it will cost and what material you need. If you don't have enough money or material, a line is drawn through it. There are some minor bugs in the screenie (I forgot to reload the player name after exiting the Blacksmith menu). Also, in this screenie I show the new saving options. The default is the slower option that hardcodes the save file into the program, but you can change to quick saving which stores to an external list.

Also, you can see the modified options in the battle menu and "Weapon" is replaced with the name of the currently equipped weapon. I still haven't even touched the spells XD

1419
An IRL friend gave me a link to a site that posted about Portal on the calc, thinking I'd be interested :D Also, the news is still spreading and it is going further and further o.o Builderboy has even done interviews, and not just on TICalc o.o

Also, the OmniRPG has been getting a bunch of attention by community members. It has actually been active. To put it in perspective, My average monthly post count is about 129. As of yesterday, I am over 70 for this month, and December is usually one of my least active months o.o It has only been 6 days for me o.o

EDIT: The average posts from July to November each month has been 3284.2. Totaling up the number of posts made by today's top 10 posters (it is 08:48 EST), there have already been 203 posts, just from them. If this rate continues, even if we average only 200 posts per day, this will still be the third most active month in the past year. This is pretty abnormal for December XD

1420
Other Calc-Related Projects and Ideas / Re: OmniRPG - Coding
« on: December 07, 2012, 08:41:42 am »
hehe, yeah, I sure hope so. And it seems that squidgetx has corroborated my guestimate of 22000 cycles for shifting the screen.

1421
Other Calc-Related Projects and Ideas / Re: OmniRPG - Sprites
« on: December 07, 2012, 08:40:37 am »
If we have over 256 sprites, we can always have sprite pallets for different areas.
Yes, that will definitely work. At 16x16 (or even 8x8) there won't even be >100 sprites on the screen st any given point.
I might have to pull back from this project a bit, life and A:P are keeping me quite busy as it is :(. I'll still be happy to act as a consultant, hehe, chipping in here and there though.

Anyway what I have to say here is that if you guys are going to go grayscale ARPG, you're going to have to sacrifice the 6mhz audience. Redrawing the screen isn't going to be an option, as that takes over 400,000 cycles by itself if you're drawing 2 layers for gray. So the screen is going to be needed to be backed up every frame to draw the enemies and whatnot; simply backing up 1,536 bytes of buffer, drawing the screen (3lvl gray) and restoring those 1,536 bytes is going to take over 123,512 cycles. In 6mhz, that's 48fps. Once you add in scrolling, enemies, and whatnot, the framerate isn't going to be anywhere close to the 45-60fps needed for decent grayscale. (Reference numbers: Horizontal/Vertical commands take about 20k cycles, drwaing an 8x8 sprite takes 2100 cycles. So scrolling with 2 16x16 grayscale sprites onscreen? Add 4*2*2*2100+2*20,000 = ~another 50,000 cycles, dropping the 6mhz framerate down to 30fps). 15mhz is going to be just about right to get you by.
I already have a much more efficient algorithm planned for scrolling a 3-level gray tilemap that should take around 50000 cycles. I posted my idea in the coding section and I have PMed chickendude for his knowledge on the subject.

Also, I have my own grayscale routine (probably not nearly as optimised as the one in Axe) that is still as fast as a regular screen update.

EDIT: Here are some sprites I found on my computer that y'all are free to use. The mini ones are the same sprites that I have been using for my other RPG series, the bigger ones were what I was designing a long time ago for an RPG featuring scrolling tilemaps with 16x16 gray tiles :P I will have to see if I have code for that, now XD

1422
Other Calc-Related Projects and Ideas / Re: OmniRPG - Coding
« on: December 07, 2012, 08:32:43 am »
I am about to send a PM to chickendude detailing my coding plan. Basically, I think I can optimise it quite a bit (maybe 200 to 100 times per second it can be rendered) by keeping a mask that I rotate with the map. Then, for left/right rotating, I just shift the screen left/right, apply the mask to the tiles with AND logic and if Z is returned, draw a pixel off, if NZ is returned, draw the pixel on. Since I am planning on 3-level gray, I will need to do this on two buffers, but even then I think it will be pretty fast. As well, since it is 3-level gray that I am planning on, I will need to rotate the grayscale mask as well. Since it is 3-level gray, that will be very easy.

By my calculations, before I do any coding, shifting the screen one pixel takes about 22000 cycles, if I remember correctly, then to test each of the sprites and draw accordingly (with optimised assembly), that will take at most 3000 cycles. On two buffers, this will be about 50000 cycles total. At 6MHz, that is 120 times it can be drawn per second (not updating the LCD). At 15MHz, that is 300 times per second. that should make the grayscale still smooth :) Also, shifting up and down will be much, much faster. Probably one or two thousand cycles for both buffers which is 25 to 50 times faster XD

I hope my calculations are correct ._.

1423
Other Calc-Related Projects and Ideas / Re: OmniRPG - Coding
« on: December 07, 2012, 08:05:51 am »
I was looking at Slova by HotDog and that is basically what I have in mind, except grayscale o.o We need to get chickendude in on this; ze is an excellent assembly programmer o.o

1424
TI Z80 / Re: Slova -- A language-learning game
« on: December 07, 2012, 07:56:40 am »
Hmm, that might be useful for OmniRPG >.> I have to make it work with grayscale 16x16 sprites.

1425
TI Z80 / Re: Slova -- A language-learning game
« on: December 07, 2012, 07:44:15 am »
Haha, that looks so nice o.o I am going to be trying to write a scrolling map engine if I get time this weekend, so I hope it looks nearly as good as that o.o

Pages: 1 ... 93 94 [95] 96 97 ... 317