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 - Matrefeytontias
Pages: 1 ... 36 37 [38] 39 40 ... 133
556
« on: January 30, 2014, 12:47:06 am »
Since you two know your ways around the VAT, I have code working for renaming an appvar with a name of the same length as the original name or smaller. I do that by overwriting the name or shrinking the VAT then overwriting the name. But how do I enlarge the VAT to have a longer name than the original one ? I tried translating everything from the name address to $982E the corresponding numbers of bytes before its original location, and translating everything from $9830 to the name address, but that only leads to VAT corrupt and memory crash. What must I do ?
557
« on: January 29, 2014, 04:38:58 pm »
Okay so my investigations led me to something interesting : you can retrieve the pointer to the VAT header of a variable given its name with GetCalc(name [,size])Asm(EB)->P. I'm trying to write the actual code you need.
558
« on: January 29, 2014, 03:04:20 pm »
It's a very painful process, and it requires ASM. Theorically, you have to find the address of the VAT header of your appvar (let's say you stored it in P), put the new name length into {P-6}, use _insertMem or _delMem at P-7 depending on whether the new name is longer or smaller than the previous one, and then write your new name from P-7 to P-7-{P-6}+1.
559
« on: January 29, 2014, 11:30:34 am »
Apparently I'm getting overflows. Lemme try harder before seeking help if it doesn't work.
560
« on: January 29, 2014, 11:21:22 am »
Okay good, now give me the separate equations for U and V and I'll try to put it in my plane deformer.
561
« on: January 29, 2014, 10:29:31 am »
Haha nice, glad to see I inspired people 
562
« on: January 29, 2014, 10:18:05 am »
I really tried everything to make it fast, I don't think it's possible that it'll ever go faster half of an FPS  EDIT : here you go  http://www.pouet.net/prod.php?which=62454
563
« on: January 29, 2014, 10:15:43 am »
Bump, Okay so I tried my best to optimize PLDEFORM like hell, and I managed to make it exactly 1023 bytes !  Since I had to drop #ExprOn, it remains 6 FPS, but I tried and at 15 MHz it's 14.30 FPS So I've made an actual demo out of it, named it Illogical (guess why ) and posted it on pouet.net and ticalc.org.While it's waiting for approval, I provide a screenshot of the 15 MHz version + download link for binaries and source !
564
« on: January 29, 2014, 01:30:07 am »
Glad to hear that it helped. This would be a great effect to have for a demoscene program. Speaking of demoscene, you should have a magnifying lens effect, as was common in demos for older systems. Also, if you want the GIFs to be smoother, crank up the framerate setting in Wabbitemu.
We're not talking about the same thing here. Lens effect can't be achieved with a single formula for U and V, it needs a whole algorithm.
565
« on: January 28, 2014, 08:19:49 pm »
Okay, so I optimized your a bit and completely replaced my drawing code by it. I also replaced the translation by a simple texture wrapping. Everything happened to work, and HOLY SHIT IT'S FAST  I really think that speed was multiplied by 6 or 7. Be ready for an awesomeness galore. Note that these screenshots are still 6 MHz and that the program is actually faster and smoother on-calc Apart from that, it now requires a little bit more than 7500 bytes of RAM, instead of the previous 13800 DEFORM.8xp is the Axe source, PLDEFORM.8xp is the executable. As before, put a number f [0, 5] inclusive in Ans before using it, no out-of-bounds test made blah blah blah. I was busy working on optimizing it
566
« on: January 28, 2014, 05:16:51 pm »
But no, in Axe I must pack the bits to plotSScreen
567
« on: January 28, 2014, 04:16:52 pm »
Actually I use another code now, based on fb39ca4's proposition. In C, it would be :
// usual for loops, x, y
plotSScreen[y * 96 + x] = texture[ tlut[y * 96 + x] ];I'll put a pointer to texture in $8000 and a pointer to tlut in $8002.
568
« on: January 28, 2014, 03:58:20 pm »
Yeah, I use 8 BPP for the texture to avoid bit unpacking. It's definitely not Axe's thing.
569
« on: January 28, 2014, 03:38:54 pm »
You don't need to unpack anything. Just store a number from 1-64 which corresponds with the index of each pixel in the texture as if it was a 1-D array.
Oh that's actually a good idea. I'll try and see how faster it is. I'm sure you can make it at least twice faster with ASM, because if I had to make the drawing code in C it would be (direct translation from Axe) :for(y = 0; y < 64; y++)
for(x = 0; x < 96; x++)
plotSScreen[y * 96 + x] = texture[ (ylut[y * 96 + x] & 7) * 8 + xlut[y * 96 + x] ];
Lemme get on my PC and I'll attach the source.
I hope this code is slightely faster, but I haven't been able to test it, so I'm not sure if it even works.
;°xlut -> A
;°ylut -> B
Render:
ld hl, plotsScreen
push hl
RenderLoop:
ld c, 8
xor a
ByteLoop:
ld hl, (A)
ld b, (hl)
ld hl, (B)
ld e, (hl)
ld d, 0
ld hl, texture
add hl, de
ld d, (hl)
inc b
TexelLoop:
sra d
djnz TexelLoop
set 0, a
jr c, TexelEnd
res 0, a
TexelEnd:
ld hl, (A)
inc hl
ld (A), hl
ld hl, (B)
inc hl
ld (B), hl
sla a
dec c
jr nz, ByteLoop
rr a
pop hl
ld (hl), a
inc hl
push hl
ld de, Plotsscreen+768
or a
sbc hl, de
jr z, RenderLoop
pop hl
ret
As I seldom have access to my PC, that will require some time before testing.
570
« on: January 28, 2014, 01:29:42 pm »
That'd only be slower. I store 2 coordinates because it's faster to access than a packed word that I'd have to decompress.
Pages: 1 ... 36 37 [38] 39 40 ... 133
|
Show Posts