Yay! moar subforums
good luck btw Iambian
Hmm, this reminds me, I need to bug Drak about his game

That's about the gist of it, Simplethinker.

Loving how things are coming along, Iambian~

Yeah, he probably uses an emulator instead.

Okay. I've run into massive problems with regard to the tilemapper. Simply put, I just don't have the CCs needed to run it without a degradation of grayscale quality, or some serious slowing. Only a few solutions present themselves:

1. Change interrupt scheme. Previously, everything's being run in the interrupt. This could change so that the "main code" would contain the tilemapper

2. Reduce framerate further to fit in the interrupts. This calls for 14FPS and a doubling up of scrolling, so it'll scroll 2 pixels at a time.

3. Restrict this project to the 83+SE/84+(SE) calculators, to take advantage of the 15MHz clock and the spare RAM.

4. Just keep trying again and again to accelerate the tilemapper. Currently, I'm using prerotated tiles with two masks to merge the tiles to achieve horizontal scrolling. The specific logic is the follows: " ld a,(de) \ and b \ xor (hl) \ and c \ xor (hl)" to achieve the sprite. C the logical not(B). Enlightening me on alternative schemes would be of best help. Currently, the tiles are interleaved and the buffer is the same, and is also vertically aligned, so if this was a simply aligned version, it would be a few LDIRs to the buffer.

Help would be appreciated in this respect.

4. Just keep trying again and again to accelerate the tilemapper. Currently, I'm using prerotated tiles with two masks to merge the tiles to achieve horizontal scrolling. The specific logic is the follows: " ld a,(de) \ and b \ xor (hl) \ and c \ xor (hl)" to achieve the sprite. C the logical not(B). Enlightening me on alternative schemes would be of best help. Currently, the tiles are interleaved and the buffer is the same, and is also vertically aligned, so if this was a simply aligned version, it would be a few LDIRs to the buffer.

Putting that in logic corresponds to: { [ ( (de) and b ) xor (hl) ] and c} xor (hl) ? the two (hl) are the same?
b=~c  then  // ~ means not()
{ [ ( (hl) and b ) xor (hl) ] and not(b) } xor (hl) ?

Now is question of using some logic rules (DeMorgan's Law, for example) *gets philosophy logic papers* And test how well it turns into z80...

EDIT: I will post all substitution rules from logic:
DeMorgan's Laws
~(A ^ B)=(~A V ~B)
~(A V B)=(~A V ~B)

Commutativity
(A ^ B) = (B ^ A)
(A V B) = (B V A)

Association
(A ^ (B ^ C)) = ((A ^ B) ^ C)
(A V (B V C)) = ((A V B) V C)

Distribution
(A ^ (B V C)) = ((A ^ B) V (A ^ C))
(A V (B ^ C)) = ((A V B) ^ (A V C))

Double Negation
A = ~~A

Contra position (technical translations are hard :S )
(A -> B) = (~B -> ~A)

Material Implication
(A -> B) = (~A V B)

Material Equivalent
(A <-> B) = ((A -> B) ^ (B -> A)
(A <-> B) = ((A^B)V(~A^~B))

Exportation
((A^B)->C) = (A->(B->C))

Tautology
A = (A V A)
A= (A ^ B)

~ = not()
V = or
^ = and
-> = conditional (I think it doesn't have interest)
<-> = bicondicional (same as above)
Searching things in:
http://en.wikipedia.org/wiki/Logical_operator
http://en.wikipedia.org/wiki/List_of_Boolean_algebra_topics                    // here look at all connectives topics (especially xor, as know as exclusive or)

Logical rules in images here:
http://en.wikipedia.org/wiki/Boolean_logic
I found there another rule:

absorption

One more thing A xor B is like ~(A <-> B)
This topic looked promising but was disappointment: http://en.wikipedia.org/wiki/Logic_minimization

Damn, now I really wanted that my BASIC program calculated this things to make sure I am doing substitutions right in the end. I have it but I haven't finished. It is going to be for my cousin. xD
 By hand it takes so much time doing truth tables.

Who is going to read all this stuff?  
ENDEDIT:


When you talked about changing buffers stuff, I had an idea that I don't know what could bring in real implementation.
The idea is to make in pairs of two bytes with dark and light layer:
(x1,y1)dark , (x1,y1) light , (x2,y1)dark , (x2,y1)ligh ...

To get the light layer is just inc hl...

[...]
When you talked about changing buffers stuff, I had an idea that I don't know what could bring in real implementation.
The idea is to make in pairs of two bytes with dark and light layer:
(x1,y1)dark , (x1,y1) light , (x2,y1)dark , (x2,y1)ligh ...

To get the light layer is just inc hl...

(to prevent the page from getting too long, much stuff was omitted,but the post can still be referenced)

When I say that the gray buffer is interleaved, what is quoted is exactly what I mean. Except that the buffer is also vertically aligned: (x1,y1)dark, (x1,y1)light, (x1,y2)dark, (x1,y2)light, ...

[...]
edit:
what size are the tiles and why do you need masks to merge the prerotated tiles?

The tiles are 16*16, but they'll be treated as 8*16 for the purposes of the tilemapper.
I'm using masks to put together the prerotated tiles to achieve horizontal scrolling. Say that the tileset has been rotated 4 times so far (to provide the illusion of moving to the side 4 pixles). The line of the tile on the left reads  %11011011 and the first line of the tile on the right side reads %01010101. The mask will be %11110000 and after the merge, the byte will read %11010101. I assume there's a faster way?

Quote from: Galandros on June 23, 2009, 03:57:01 am

[...]
When you talked about changing buffers stuff, I had an idea that I don't know what could bring in real implementation.
The idea is to make in pairs of two bytes with dark and light layer:
(x1,y1)dark , (x1,y1) light , (x2,y1)dark , (x2,y1)ligh ...

To get the light layer is just inc hl...

(to prevent the page from getting too long, much stuff was omitted,but the post can still be referenced)

When I say that the gray buffer is interleaved, what is quoted is exactly what I mean. Except that the buffer is also vertically aligned: (x1,y1)dark, (x1,y1)light, (x1,y2)dark, (x1,y2)light, ...

that actually sounds like a ridiculously good idea afaik.  in practice it's probably hard to implement

Quote from: SolusIpse on June 23, 2009, 10:37:24 am

[...]
edit:
what size are the tiles and why do you need masks to merge the prerotated tiles?

The tiles are 16*16, but they'll be treated as 8*16 for the purposes of the tilemapper.
I'm using masks to put together the prerotated tiles to achieve horizontal scrolling. Say that the tileset has been rotated 4 times so far (to provide the illusion of moving to the side 4 pixles). The line of the tile on the left reads  %11011011 and the first line of the tile on the right side reads %01010101. The mask will be %11110000 and after the merge, the byte will read %11010101. I assume there's a faster way?

i can't imagine a messuptiles being faster.  are you storing the pieces into a buffer? like are you buffering the pieces before the merge?  i'm guessing you're not building every combination on the fly?

if you can get prerotation such that it's stored in a buffer where each tile is 3 bytes wide (left, middle, right byte of the rotated 2 bytes), you can just grab pieces as needed.  i'm still a bit confused as to what you mean by prerotation.

I hope it works out