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 - ZippyDee
Pages: 1 ... 6 7 [8] 9 10 ... 51
106
« on: January 30, 2012, 08:22:24 pm »
It must be Opera, because mine did the same thing, DJ.
107
« on: January 30, 2012, 03:33:44 pm »
Welcome to Omnimaga! Have some peanuts!  EDIT: Wow ninja'd by 13 seconds!
108
« on: January 30, 2012, 03:27:21 pm »
Something like this?
Note that the two blue pixels would be black on the outline, but would be changed to dark gray when the outline is removed, and the green pixel will stay dark gray when the outline is removed. I just colored them to show where the pattern would be on the default tile.
109
« on: January 30, 2012, 02:55:52 pm »
Well if you look at the original MiniCraft, the "mountains" really just look like elevated terrain, not actual mountains. That's all I was really capturing there.
110
« on: January 30, 2012, 02:36:35 am »
Here's just five 16x16 sprites of Mario that I threw together. They'd be even better if it were 4-level grayscale, but I think these look pretty good for 3. 
111
« on: January 29, 2012, 09:05:24 pm »
I know it'd slow down the tilemapping quite a bit, but maybe there's a way to make the mountains look at lot better by giving them contiguous outlined edges... The idea would be to check the 8 surrounding tiles to test if they are mountains as well. For each surrounding tile, there would be a sprite to XOR onto a default mountain tile sprite, removing that wall/corner outline from the sprite. How plausible is this? Here's an example:  (The bottom 8 sprites are supposed to be inverted like that so the XOR removes them) The top sprite is the default mountain sprite. Before drawing the tile, that would be copied to a temporary memory area. The other tiles would be XOR'd onto the temporary sprite to remove that outline based on surrounding mountain (in order: top-left, top, top-right, left, right, bottom-left, bottom, bottom, bottom-right). The result would look something more like the example I threw together below the sprites. Obviously it would make it slower, but the question is how much slower?
112
« on: January 28, 2012, 03:08:22 pm »
You could break it down into smaller images and splice it together...
113
« on: January 26, 2012, 01:28:48 am »
why not have a flag of some sort set that determines what mode to use? Then it wouldn't have to have an entirely new routine, it would just have to check the flag when it gets to the xor/or/cpl-and part...Sure, that may slow it down a bit, but it would cut down on size a lot, I'd think.
And, of course, that would only be included if more than one mode was used in the program.
114
« on: January 25, 2012, 01:03:05 am »
Hmm... I guess that does make sense. Looking back over that I realize that I was thinking of shifting the multiplicand (like the example shows) rather than the running total.
115
« on: January 25, 2012, 12:48:05 am »
Er...no, you should be starting on the right still...
I believe jacobly's post should have said:
11001100 = a
× 10010110 = b
----------
00000000
11001100
11001100
00000000
11001100
00000000
00000000
+ 11001100
-----------------
111011110001000
So as you can see, in binary, for each bit you add either 0 or a (shifted by some amount), depending on the corresponding bit in b.
The way this is usually done is:
1. shift the running total left one bit
2. check the lsb of b
3. if set, add a to the running total
4. shift b right one bit
5. repeat steps 1-4 for each bit in b
6. the answer is the current running total
116
« on: January 24, 2012, 07:09:46 pm »
An example may help:
11001100 = a
× 10010110 = b
----------
00000000
11001100
11001100
00000000
11001100
00000000
00000000
+ 00000000
-----------------
111011110001000
So as you can see, in binary, for each bit you add either 0 or a (shifted by some amount), depending on the corresponding bit in b.
The way this is usually done is:
1. shift the running total left one bit
2. check the msb of b
3. if set, add a to the running total
4. shift b left one bit
5. repeat steps 1-4 for each bit in b
6. the answer is the current running total
I think there is a mistake in that written out example...Shouldn't the last iteration be adding 10010110, not 00000000? Also, shouldn't step 4 be "shift b right one bit"?
117
« on: January 23, 2012, 12:04:48 am »
Heh...It'd be cool to be able to have your screen burning with grayscale fire while using the calc normally.
Those kind of mods are rather difficult as many OS processes only update the screen and nothing else. That means it would be difficult to keep a memory of what was actually on the screen.
The only solution I see would be to read the entire LCD back before every single grayscale interrupt and compare it to a known copy of what the screen looked like. This however would require two full screen updates and therefore 100% of cpu time at 60hz. It should run at 30hz though.
So, if I get bored... (Or if xeda gets bored (make a getCSC hook that enables your interrupt  ))
Oh yeah, I hadn't thought of the fact that the OS tends to write directly to the LCD :\
118
« on: January 21, 2012, 04:53:40 pm »
Heh...It'd be cool to be able to have your screen burning with grayscale fire while using the calc normally.
119
« on: January 21, 2012, 06:23:02 am »
Okay, I just wanted to make sure. If you only use it with positive then Math.floor will do the trick for sure.
120
« on: January 21, 2012, 06:14:43 am »
I believe that works like BASIC's int() though, not like iPart(), meaning that it rounds everything down. So -1.9 is -2 instead of -1...
If you want to have it round then just write a function like
function ipart(x){
if(x<0)return Math.ceil(x);
return Math.floor(x);
}
and use ipart(value) to get the integer part.
Pages: 1 ... 6 7 [8] 9 10 ... 51
|
Show Posts
