Post by: Halifax on December 09, 2006, 11:19:00 am
Background:
This game is on the life of an ex-marine who fought in the space war of 2010(civilization has made a great advance since 2006). His mind has been messed with a lot over the years of war and he has become subject to many mental challenges. He believes that everybody is out to get him and he is still fighting in the war of 2010. Equipped with his rudementary tools, a chainsaw, machine gun, and knife, he begins his mission to take out all the aliens with no prisoners held.
This game is based heavily on blood. There will be much to see in terms of the blood effects so if you are into heavy violence then this game will be for you.
NEWS for DCS6 users:
Also I am thinking about making this exclusive to DCS6 only for the mouse routine use with the in-game menus, but if DCS6 is not done by then then I will just have to make my own mouse routine and realese it under MOS.
Post by: DJ Omnimaga on December 09, 2006, 11:34:00 am
Post by: Halifax on December 09, 2006, 11:44:00 am
Post by: elfprince13 on December 09, 2006, 11:57:00 am
| QUOTE (Halifax @ 9 Dec, 2006, 17:19) |
| NEWS for DCS6 users: Also I am thinking about making this exclusive to DCS6 only for the mouse routine use with the in-game menus, but if DCS6 is not done by then then I will just have to make my own mouse routine and realese it under MOS. |
post this on cemetech, kerm will probably give you a big hug.
wootz for DCS
Post by: DJ Omnimaga on December 09, 2006, 12:00:00 pm
, well at least I'm glad people are taking advantage of DCS routine now :DKerm do visit here too sometimes though so he may see this here too
Post by: Halifax on December 09, 2006, 12:11:00 pm
Post by: DJ Omnimaga on December 09, 2006, 12:47:00 pm
else ppl may miss it here x.x
Post by: kalan_vod on December 09, 2006, 01:08:00 pm
Post by: KermMartian on December 09, 2006, 06:25:00 pm
Post by: DJ Omnimaga on December 10, 2006, 02:33:00 am
Post by: KermMartian on December 10, 2006, 03:22:00 am
Anyway, the mouse routine doesn't require a hardware mouse at all... and yes, it already has an acceleration system built in.
Post by: DJ Omnimaga on December 10, 2006, 03:30:00 am
it still went at the same speed than in doorCS 5. I'M using TI-83+ and SE with OS ranging from 1.12 to 1.18 btw.
Post by: Halifax on December 10, 2006, 09:32:00 am
NOTE: If trying to accees the Psugen site manually then do not type in a www. or a http://
Post by: DJ Omnimaga on December 10, 2006, 10:16:00 am
Post by: Halifax on December 10, 2006, 10:39:00 am
Post by: DJ Omnimaga on December 10, 2006, 10:49:00 am
Post by: Halifax on December 28, 2006, 09:34:00 am
Comments?? Too fast??Too slow(yeah right haha)??
Post by: Spellshaper on December 28, 2006, 09:44:00 am
Post by: Halifax on December 28, 2006, 10:01:00 am
Note:I could make it even faster if I didn't update the tilemap every single time the guy moves :)
Post by: Liazon on December 28, 2006, 01:57:00 pm
Post by: Halifax on December 28, 2006, 02:09:00 pm
j/k j/k.
Post by: DJ Omnimaga on December 31, 2006, 10:44:00 am
Post by: Halifax on December 31, 2006, 11:51:00 pm
@xlibman: srry xlibman but these aren't gameplay sprites :(
they are just test sprites to show the engine.And this screenshot shows all our latest work with tilemaps,walking,sprite routines, and hit detection. And it works yay!!! Now we got to add some scrolling tilemaps and combat stuff or more tiles and a demo program mayb on the way.
Post by: DJ Omnimaga on January 01, 2007, 04:38:00 am
EDIT: YAY works now. I like it so far.
Post by: Liazon on January 01, 2007, 10:30:00 am
Post by: graywolf on January 01, 2007, 10:39:00 am
Post by: Halifax on January 01, 2007, 12:43:00 pm
Post by: DJ Omnimaga on January 08, 2007, 12:19:00 pm
Post by: Jon on January 18, 2007, 06:21:00 pm
For my hateful behavior on IRC, and insubordination towards leadership, I have been booted from Psugen Staff. Though the action was most certainly justified (I insultingly rewrote the NPC routine, talked a bunch of crap behind Halifax's back, and I horribly overstepped my former job as routine programmer :banghead:
), I am still asking to be forgiven. :( It is easy to see why halifax had a growing paranoia of me stealing his project, being that I posted on Maxcoderz without his consent. I just want him and everybody else to know that The Massacre is HIS project, not mine, and I would never steal it. I just hope he will allow me to help out here and there, as it is the coolest project I have ever seen. And whether I'm allowed to help out again or not, I wish the best of luck on The Massacre. XD
Post by: DJ Omnimaga on January 19, 2007, 02:16:00 am
. We all do mistakes btw. *xlibman
Post by: Halifax on January 19, 2007, 09:20:00 am
note: Jon and I have never been in bad terms on my side
another note:Let's try to stay away from personal stuff in this forum thread as it is strictly game talk
Post by: DJ Omnimaga on January 19, 2007, 02:15:00 pm
Post by: Jon on January 19, 2007, 04:54:00 pm
Post by: Halifax on January 20, 2007, 04:23:00 pm
Post by: trevmeister66 on January 20, 2007, 04:32:00 pm
Post by: CureDesu on January 20, 2007, 04:39:00 pm
Post by: trevmeister66 on January 20, 2007, 04:41:00 pm
Post by: Halifax on January 20, 2007, 04:44:00 pm
Post by: trevmeister66 on January 20, 2007, 05:21:00 pm
Post by: Halifax on January 20, 2007, 07:39:00 pm
Post by: trevmeister66 on January 21, 2007, 03:21:00 am
Post by: DJ Omnimaga on January 21, 2007, 05:09:00 am
Post by: Jon on January 21, 2007, 05:34:00 am
Post by: Liazon on January 21, 2007, 07:07:00 am
Post by: Jon on January 21, 2007, 07:22:00 am
| QUOTE |
| you could just use saferams and the "malloc" trick |
what's the malloc trick?
Post by: Liazon on January 21, 2007, 07:57:00 am
Post by: Halifax on January 21, 2007, 01:13:00 pm
Post by: Liazon on January 21, 2007, 01:35:00 pm
or there's wasted space. regular 83+BE have few pages available to the user.
Post by: Delnar_Ersike on January 21, 2007, 01:38:00 pm
Post by: Halifax on January 21, 2007, 01:44:00 pm
Here is an image of it using Massacre as an APP. As you can see it is clearly the same and as fast as stub version.
Post by: necro on January 21, 2007, 02:07:00 pm
Post by: DJ Omnimaga on January 21, 2007, 02:21:00 pm
in the affiliates it seems to work tho
Post by: CureDesu on January 23, 2007, 01:40:00 pm
Post by: bfr on January 23, 2007, 01:51:00 pm
Post by: trevmeister66 on January 23, 2007, 01:53:00 pm
Post by: graywolf on January 23, 2007, 01:55:00 pm
Post by: Delnar_Ersike on January 23, 2007, 04:00:00 pm
Post by: trevmeister66 on January 23, 2007, 04:02:00 pm
Post by: Halifax on January 24, 2007, 07:27:00 am
2 frames for each direction and then corresponding masks for those 8 frames which makes 16 in all. And believe me bullets will go faster.Thanks for all the support to guys it really makes you want to work :P
Post by: Speler on May 06, 2007, 04:42:00 am
Post by: Halifax on May 06, 2007, 02:51:00 pm
Post by: Speler on May 06, 2007, 03:03:00 pm
Post by: Halifax on May 14, 2007, 09:20:00 am
I was sitting around one dark and dreay night staring at Jim_e's tilemapper code, a modified version of Dwedit's but faster, and I was thinking. Crap this goes really slow when you have 255 tiles because you have the shift 2040 bytes. So I was like how the hell can I make this faster! Well I have come up with two plans that may or may not work because I have not timed them out yet.
1. Well let's say we can cut down how many tiles it has to shift. I have come up with a plan to find out the 96 tiles, 12x8, that the tilemapper will be mapping. Then all you have to do is shift 96 or less tiles instead of 255 tiles. So that should be a great speed boost although the process of making sure there are no duplicates is very hard although I will try.
2. Well if the offset that the tiles will be shifted is 7 them that's going to take a d*** long time to shift all of those tiles to the left. So then I got an idea why not split them. If the offset is between -3 then start in the left byte and if it is between 4-7 then start in the right byte. So it's like this
Offset between -3
---- shift right
%11111111,%00000000
Offset between 4-7
<------ shift left
%00000000,%11111111
So that means that there will only be a maximum of 3 shifts or less to do then 7 or less. I think these will do a considerable job in speeding up the process of the smoothscrolling tilemap.
I will begin dissection of Jim_e's cryptic code tonight o.o
Post by: Speler on May 14, 2007, 09:23:00 am
Post by: graywolf on May 14, 2007, 12:54:00 pm
Post by: Halifax on May 14, 2007, 02:19:00 pm
Post by: Jon on May 14, 2007, 02:24:00 pm
make jim_e's code an inc file, and .org it to $9d95, then at runtime, copy the code to $9d95, and then call it. Then it'll be in RAM, and can use SMC as needed.
PS: make sure you clear out $9d95-$bfff before exiting the app, or bad things will happen.
Post by: Halifax on May 14, 2007, 02:26:00 pm
Post by: Jon on May 14, 2007, 03:09:00 pm
Post by: Halifax on May 16, 2007, 02:44:00 pm
That was not fun, but it's alright I got through it and dissected it fully. Things are running smoothly and I have went on to start writing my own app-friendly tilemapping routine. So with how it's going I am definetly thinking it will be posted by this weekend or week.I am currently on to writing the tile detection routine that detects all the tiles that are going to be written to the screen.
Post by: Fallen Ghost on May 16, 2007, 03:44:00 pm
If you need any help, I'll be very willing to give some of my time.
12 height or 12 wide? cause 12 wide is pretty strange and non-efficient, 16 wide would be better, but in case you meant 8 wide, then it's good. still 16 could be more efficient if it was possible.
Post by: Jon on May 16, 2007, 09:57:00 pm
An app-friendly tilemapper! How could one not be interested??
Post by: calc84maniac on May 17, 2007, 02:10:00 am
Post by: Liazon on May 17, 2007, 04:58:00 am
Post by: Halifax on May 17, 2007, 08:29:00 am
@Fall_Ghost: Haha it's funny you say that because you usually are the first one I come to for anything about apps. But yeah I will probaly need you for the 16x16 app-friendly tilemapper, but so far I have like half of the 8x8 tilemapper code working in an app and debugged fine.
Oh yeah and I am keeping this on the same track so both the 8x8 and 16x16 tilemappers will be open-source!
wow and I never knew app-friendly smoothscrolling tilemappers were so special. Aren't there already like a couple out there??
Post by: Fallen Ghost on May 17, 2007, 01:32:00 pm
Anyway, I'm interested in it cause I'll probably port it from 8*8 (all in bits dimensions) to a clipped 16*X version supporting less features but including special other specific things. But smooth-scroll will definitely be a nice option.
Oh, it would definitely be nice if I could get a link to Jim_e's tilemapper... I might even just copy parts to ram and such, to make it easier.
Post by: Halifax on May 17, 2007, 03:30:00 pm
16*x would be awesome but I don't know I have been thinking about it. For a 16x16 or 16*x tilemap or anything to do with 16 in the style that Jim_e/Dwedit does it would take 3 buffers equal in size to the tilemap buffer. Which would mean 2 16x16 tiles would require 256 bytes which is pretty harsh just for two tiles.
I would try and think of a new method of tilemapping.
Post by: Speler on May 17, 2007, 03:42:00 pm
Post by: Fallen Ghost on May 17, 2007, 03:48:00 pm
If you prefer, 16 bits wide*X bits high per tile (probably 14-16, what crappy numbers) and near 15-20 tiles max.
The total amount of tile in 1 map should be what, 128*64... 8192 bytes, but 4092 if we compress. lol, ok, maybe not.
No tilemapper for SC until I reduce map size.
But I still give you my help for the tilemapper.
Post by: Halifax on May 17, 2007, 04:06:00 pm
255*256 = 65280 bytes. Which is very unusable, but 255 8x8 tiles would be
255*24 = 6120 bytes. So basically I could have 765 tiles that only take up one page and a little more(I won't have that many) And then I will be fine. So I think that is one reason I will stick with 8x8 because it is more versatile.
Post by: Jon on May 17, 2007, 04:22:00 pm
Post by: Halifax on May 18, 2007, 10:51:00 am
Post by: bfr on May 18, 2007, 11:10:00 am
You could just do what I often do, and try to get on IRC Friday-Sunday. ;)
Post by: Halifax on May 18, 2007, 05:07:00 pm
Post by: Halifax on May 20, 2007, 02:51:00 am
c1-->
| CODE | ||||||
| ec1 ;This source is fully commented out so that even a total n00b could understand this. ;If any questions still arise =) then just email me: [email protected] for more info ;################################################################################### ;Fastcopy + Horizontal + Vertical Scrolling Tilemap by Jim e || Comment out like a n00b by Halifax ;Based on dwedit's mapper ;Messuptiles is 50% faster ;The mapper is 14% faster. ;Like it needed to be faster;) ; ; ;Input: ; Post by: bfr on May 20, 2007, 04:01:00 am Read the directions carefully. mapAdress: .dw addressOfMap tilesAdress: .dw addressOfTiles Note how Jim E. says (tilesAdress), not tilesAdress. :) Post by: Liazon on May 20, 2007, 04:13:00 am 1) where you want your screenbuffer to be 2.)which map to read 3.)what tileset to use 4.)how wide the map is The only bad thing is that the number of tiles in the set is constant, so you'd waste time rotating nothing even if you have less tiles than your max. probably could be fixed with a little SMC and multiplication :) Good Job Post by: Halifax on May 20, 2007, 08:04:00 am tilesAdress = saferam ... ld hl,tileset ld (tilesAdress),hl Post by: bfr on May 20, 2007, 08:19:00 am Post by: Fallen Ghost on May 25, 2007, 02:58:00 pm Destructible tileset buffer means you need to ldir all your tileset from it's originial location or just a buffer equal in size? Great, I'm a noob using tilemappers so I need a little course of how to use it. Then I'll debug. 1)what is the format for the tilemap? (not the tileset, I talk about the thing that represents each tile on the map) Is it 1 byte/tile? (I guess so, but just to be sure) 2)hell, what a brick to read. I love comments, but less would not be a big matter. I know it's better with complete sentences and all, but we aren't stupid neither. Oh and please, next time you show up code, do us a favour and separate your code of comments with at least 5-10 spaces (horizontally) so that semicolon isn't the next char after the instruction. And it would be fun to differentiate routines of code continuations (like a big header of "now my code is multiplying, no more bit shifting, just additions" would be replaced by "[instruction].....;multiplications here") But those are no debug logs, so I'll run up and check it out now. [looking at code] 3)messing up tiles and finding rotations? what? kk, save tiles and change bit positions according to X. 4)from what i've seen, tilesbuf2 is the buffer where the byte+inverted mask is, so that you know where you can write and where you cannot for the other rotated+clipped tilesprites can be applied. But how come 2 tiles would overlap in any way? Post by: Halifax on May 25, 2007, 04:39:00 pm . Secondly maybe you should do a trace of the routine and that will provide you with a good understanding, Thrid off the routine needs no debugging it works, Fourthly I need to talk to you about an effcient way to search for tiles and... so on, but I would rather talk to you in realtime because it is a little more than a little explanation. So you have any realtime contacts at the moment??
Post by: Liazon on May 26, 2007, 03:28:00 am
IIRC, it's kinda been awhile sorry. 0.) i'm pretty sure (tilesaddress) can be in ROM, but you need buffers of equal size in RAM somewhere. I'm pretty sure iirc that the routine just reads the tiles from their source and saves the modifications in the buffers. 1.) ya, 1 byte per entry, so 256 tiles max. 117 or less is the most efficient. Anything above will seriously lose to a planeshifting tilemapper iirc. Still, I can't imagine needing so many black and white tiles since you could always change the tileset address that the routine reads from. 2.) well, I do admit I wish that forum code boxes had syntax highlighting, but http://www.revsoft.org/phpBB2/viewtopic.php?t=644&start=0 3+4.) The concept behind this tilemapping technique is based on around the idea that an unaligned sprite will ALWAYS take up 2 bytes (if it's aligned for a moment, you can still say the second byte is %00000000). If you look at ionputsprite, you notice that it too must split the sprite into it's two parts through rotations before it can write to the buffer. Jim e just applied that to the tilemapper by pre-shifting EVERY TILE into it's two parts and saving one part in one buffer, and the other part in another buffer. When it comes time to write, all you need to do is take the second part of the first tile and XOR/OR it with the first part of the tile next to it. It's like putting unaligned sprites next to each right next to each other. They both must share bits in the same bytes, the ones in the middle. Hope that helps. I'm pretty sure the only way to really use this in an app right now is to copy into reserved $9d95 space. Post by: Fallen Ghost on May 26, 2007, 04:06:00 am 1)rotate all tiles from tileset into buf1 and buf2 (named after their according byte from sprite 2)fetch what tiles are used and what height/width of them is taken to fetch good bytes 3)bitwise OR with two tile parts into acc 4)out to LCD data port I just copied the code in ZDS and everything looks way better with colours Wasn't it supposed to be an app-friendly tilemapper using no SMC? I'm very loaded up with school but just give me a time and I'll probably be there. Like tonight 6-10 GMT-5? [Edit]there are 2^64 possibilties for a 8*8 tile so I guess you can have alot and alot of them a tilemap of 16*16. isn't that a bit small for a complete map? Post by: Halifax on May 26, 2007, 04:50:00 pm Don't you guys read my posts at all?? I think I remember clearly stating I am posting a commented out source so that other people can understand it faster and mod it. Post by: Fallen Ghost on May 27, 2007, 01:52:00 am Post by: Liazon on May 27, 2007, 03:08:00 am the idea is that a 64x96 pixel screen can only show 8x12 8x8px tiles, which is 96 tiles on the screen. Now most of the time, tiles get reused in order to create graphical structures like roads, trees, building, etc. If they are going to reappear multiple times, there is no point in rotating the same tile every time it appears. you might as well rotate them once and simply copy the prerotated data into where it goes. This works the best when you have less tiles in your world (ie, Digitan's Robot Wars actually only uses 32 tiles max in each level) When you have less tiles than 96, the chance that you reuse the tile is higher. If you have to reuse tiles, then messuptiles is more efficient than ionputspriting in a loop, and probably more efficient than planeshifting. I thought 96 was ideal, but for some reason Jim documents 117 or less as the most efficient, but that's probably using a direct comparison of t-state usage between all the other methods and Dwedit's original messuptiles mapper. I know StarCalc will probably use a lot of tiles, so maybe messuptiles isn't ideal for what you need FallenGhost. I don't know. Like I said, this just one of the methods of tilemapping I've seen. Post by: Fallen Ghost on May 27, 2007, 12:01:00 pm Uh, as the maps are 128*128 (16*12 pixels), I don't plan to add mapping so much because it will take too much space. I rush like hell to add vital functions such as attack move (come on, that's essential) without lag. The thing that takes the most time for now is the map exploration, so maybe that'll be the thing that goes off... sadly (let's say 200 times putspriteclip (sigma's) is long to do) but if I remove map exploration, maybe I might be able to add a tilemapper with the space saved. I'll probably use something like 32 tiles too. Post by: Liazon on May 27, 2007, 03:19:00 pm It's so uber optimized that you can only use 32 tiles at most, you have to use buffers that start on an address like this: $XY00 where X and Y are digits. Most importantly, the buffer is vertically aligned. That means adjacent bytes in memory represent vertically adjacent groups of 8 pixels on the screen. In other words, very difficult to use, but extremely fast, which really gives digitan a lot of clocks to work on physics based stuff. It sounds like you've got a plan though. Post by: Halifax on May 27, 2007, 05:28:00 pm Post by: Fallen Ghost on May 28, 2007, 02:35:00 pm I have to use buffers that use strange addresses, ok, well, I guess that's not much of a problem, just do all your bcalls, then transfer some of TI's code in ram to other useless spaces (like some unused rampant asm spaces), then re-transfer them back before bcalling again. And if I understand, X and Y are flipped up. Ok, fits alot better with LCD port. Why not? Now you just got to figure out some things like drawing characters and stuff over it before it draws, but it's now much more easy! Whatever I'll find it out when I'll use it. Now back to subject Halifax, what did you need to iron out with me for the code? (can be via pm) Post by: bfr on June 02, 2007, 08:52:00 am Relating to the Massacre...wasn't it originally in BASIC+xLIB? Will the BASIC+xLIB version ever be finished? Post by: Halifax on June 02, 2007, 11:39:00 am Yes it was originally BASIC+xLIB. Simply put...H*** no. There would be no point in finishing it since XBASIC can not match up to ASM when it comes to action games. Anyways there are no updates for the Massacre because I have been busy with finals which SUCK. Some good news is that I tested out(I won't have to take it next year) Computer Concepts 2, and Advanced Programming Techniques since they were both about C++ programming. So I have to take this philosophical type of computer course next year about optimization and how to figure out optimizations on high-level by the low-level x86 assembly. After that in my junior year it is on to my college computer courses!!!!!! :)
Post by: bfr on June 02, 2007, 12:58:00 pm I hope I don't fall behind in computer programming.... I might be able to take an online course, though....
Post by: Halifax on June 02, 2007, 02:13:00 pm lol.
Post by: Halifax on June 07, 2007, 03:10:00 pm As I said this was a quick hack so I will optimize it and implement the stuff above before releasing the source code.(And embarassing myself with it lol). Well for your non viewing pleasure :( , because PTI grayscale screenshot taking sucks.
Post by: Speler on June 07, 2007, 03:13:00 pm Post by: Fallen Ghost on June 07, 2007, 03:51:00 pm *Fallen Ghost Post by: bfr on June 07, 2007, 04:12:00 pm Good luck with that. :P I hope you can pull this off (with a decent size and speed). :thumbup:
Post by: Delnar_Ersike on June 08, 2007, 04:42:00 am Post by: Halifax on June 08, 2007, 08:37:00 am @Fallen_Ghost: No no no it isn't just PTI greyscale. I am using Jim_e's same map but with animation. The grayscale effect is caused by flipping a black and white 8x8 tile back and forth. I should have made a better example. Secondly yes yes code is coming I just have to clean it up a little bit and optimize. Trust me I am going to keep this fully opensource. @bfr: Wooo cowboy hold up. Grayscale is supported. As I said it is just flipping the black and white tile which is causing the greyscale effect. Trust me I will post a better example later. Also size for the animation only took about I would say 30 lines of code. Jim_e did a lot of good work and that included making his mapper easily moddable. That's why I love it. Anything else you gyus would like to see in a tilemapper?? I can't think of anything past just animation, but maybe you guys can. Post by: calc84maniac on June 08, 2007, 10:11:00 am
Post by: Harrierfalcon on June 08, 2007, 10:41:00 am
Post by: Halifax on June 08, 2007, 11:36:00 am (Old and bad)Wabbitemu Screenshot:  (Good and new)Wabbitemu Screenshot:  EDIT: The other one was animating both tiles because there was a problem in the tilemapper but now I fixed it and optimize the loop a little bit more and it runs at 75 FPS now! Anyways I found out that it moves at 73 FPS so I would suggest capping your framerate at 4-46 FPS if you want to get smooth animation and not grayscale like animation. Oh yeah and nevermind Multiple frame animation will not be possible. You will only be able to do it by the number of frames you set. So for example: If you pick 3 frame animation then for all the animated frames you need 3 frames and for the non-animated ones you need 1 frame. If you pick 4 frame animation then you will need 4 frames for all the animations and 1 for non-animated and so on. Post by: DJ Omnimaga on June 08, 2007, 01:06:00 pm Post by: Halifax on June 08, 2007, 01:52:00 pm Post by: Fallen Ghost on June 09, 2007, 05:56:00 am Post by: Halifax on June 09, 2007, 07:06:00 am Post by: Fallen Ghost on June 09, 2007, 03:30:00 pm And no, it can't be possible you get 75 FPS not including GS, cause it would mean 150 refreshes, so 6 000 000 clocks (counting on a 83 +BE)/150=40k T states, 7k less than rigview and 12k less than Fastcopy. Post by: Halifax on June 09, 2007, 04:24:00 pm Post by: Jon on June 09, 2007, 10:28:00 pm  that's insane halifax. A tilemapper going that fast?
Post by: tr1p1ea on June 10, 2007, 02:53:00 am Also how many tiles will you be using in this game? Jim's tilemapper is only really fast with a limited amount of tiles. Also, wabbit isnt 'leaps and bounds' ahead of PindurTI. They arent actually very different, unless you consider a GUI a huge step forward (which it isnt). The LCD emulation is also unrealistic, but that was done deliberately. They are both really great emulators, either of which would be a better alternative to the likes of VTI/Flash Debugger. Post by: calc84maniac on June 10, 2007, 09:53:00 am
Post by: Halifax on June 10, 2007, 01:15:00 pm Post by: Insanity on June 10, 2007, 01:19:00 pm It totally Pwns xLIB's Tilemap function :P
Post by: bfr on June 10, 2007, 03:16:00 pm
Although it looks cool already, if you want it to be animation without grayscale, you could probably set up some sort of interrupt. Post by: tr1p1ea on June 10, 2007, 07:10:00 pm Post by: Halifax on June 10, 2007, 11:40:00 pm @bfr: Yeah I know I was just showing that animation worked not the way I would be using it. Thanks though. Also @tr1p1ea: And what tilemapper would you suggest if I had a lot of tiles? Or how would you suggest I make it? I tried MiSSTeR which just maps the tiles aligned and then shifts the whole screen, but I was wondering if that is really faster than this. Post by: Liazon on June 11, 2007, 03:07:00 am I think the major difference between messuptiles and planeshifting is that the speed of planeshifting does not depend on the number of tiles, which means that the speed will depend on how well it is written. On the other hand, messuptiles has a set # of clock cycles for each tile rotated, which according to Jim e iirc is the major bottleneck. The overhead (required cycles) isn't too bad, iirc, it's about the same as a fastcopy. I'd probably go with Jim's sugggestion of 117 tiles or less. Or just calculate the # of clocks needed for X tiles using his calculations in the comments. Then see if it's less than the total speed of the planeshifter. Of course, then you probably wouldn't be able to use Jim's animated mapper Post by: calc84maniac on June 11, 2007, 04:21:00 am Post by: Halifax on June 11, 2007, 06:36:00 am @Liazon: He hasn't released his animated tilemapper source and that's why I made my own. Which only slows the loop for rotating the tiles down by about 1-15 cc's per tile. Isn't a bad tradeoff in my mind. Post by: calc84maniac on June 11, 2007, 02:58:00 pm Post by: Speler on August 02, 2007, 10:36:00 am Post by: DJ Omnimaga on August 02, 2007, 10:59:00 am
:lmao:  Post by: Halifax on August 02, 2007, 03:39:00 pm you can have a macro like this macro(x1,x2,x3,x4) but have it called like this macro(4, 5) and your macro can check what arguments were passed and what ones weren't. Anyways in other news I have scrapped Jim_e's tilemapper. I am currently working on a homemade plane-shifting LUT tilemapper. Post by: DJ Omnimaga on August 02, 2007, 03:52:00 pm |