Five clock per pixel RLE mode
-
- Posts: 1445
- Joined: Mon Feb 11, 2013 8:08 am
- Location: Brisbane, Australia
Re: Five clock per pixel RLE mode
Clever is what I do
Sadly quick does not seem to be what I do. Been 8 months since I made much movement on this.
I started working on a new demo for this mode this morning. Should hopefully be able to drop some jaws.
Sadly quick does not seem to be what I do. Been 8 months since I made much movement on this.
I started working on a new demo for this mode this morning. Should hopefully be able to drop some jaws.
- nicksen782
- Posts: 714
- Joined: Wed Feb 01, 2012 8:23 pm
- Location: Detroit, United States
- Contact:
Re: Five clock per pixel RLE mode
I certainly am looking forward to it!
CUzeBox doesn't have the patch officially yet, right? Jubation mentioned integrating it into the emulator. Has that happened yet?
CUzeBox doesn't have the patch officially yet, right? Jubation mentioned integrating it into the emulator. Has that happened yet?
Re: Five clock per pixel RLE mode
Sadly no. Life stuff intervened when I originally wanted to do it, and nowadays it's such a mess around me that I can't really do it, I am totally pooped.nicksen782 wrote: ↑Thu Aug 16, 2018 4:43 pmCUzeBox doesn't have the patch officially yet, right? Jubation mentioned integrating it into the emulator. Has that happened yet?
CunningFellow: Could you fork the emulator with your patch? For now that's the best solution, so there would be a version on GitHub which you could use if you wanted to play around with the RLE mode (the patch isn't good for anything else as it only adds a crude solution to make the RLE mode work).
-
- Posts: 1445
- Joined: Mon Feb 11, 2013 8:08 am
- Location: Brisbane, Australia
Re: Five clock per pixel RLE mode
Seeing as the forum was slow at the moment I was going to post a still picture from my current demo I am working on.
I was not ready to post the demo because from some angles the picture broke up. I thought it was a problem with hidden surface removal.
Turns out it was the Y=MX+C to RLE converters limitations interacting with the more complex scene.
I always knew the converter was basic but thought I was going to deal with that on the C side. Turns out that is a bit hard.
I have spent quite a few hours and now the Y=MX+C to RLE converter can cope with crossing lines. If two or more lines cross at the same point, the (n+1)th line becomes invisible till the next scan line which can lead to 1/M pixels of the wrong colour. No one will notice that if it does ever happen.
Anyway - here is a still shot of the new encoders results. The lime green line crosses over the blue and pink lines. In the previous version this kind of crossing would cause one line to disappear and the crossed line to bleed into the next transition.
I was not ready to post the demo because from some angles the picture broke up. I thought it was a problem with hidden surface removal.
Turns out it was the Y=MX+C to RLE converters limitations interacting with the more complex scene.
I always knew the converter was basic but thought I was going to deal with that on the C side. Turns out that is a bit hard.
I have spent quite a few hours and now the Y=MX+C to RLE converter can cope with crossing lines. If two or more lines cross at the same point, the (n+1)th line becomes invisible till the next scan line which can lead to 1/M pixels of the wrong colour. No one will notice that if it does ever happen.
Anyway - here is a still shot of the new encoders results. The lime green line crosses over the blue and pink lines. In the previous version this kind of crossing would cause one line to disappear and the crossed line to bleed into the next transition.
Re: Five clock per pixel RLE mode
Sure this will be something wicked! Wish to see some more
By the way would it be possible to get rid of the UART hack if you had a kernel which doesn't use the COMPB interrupt?
By the way would it be possible to get rid of the UART hack if you had a kernel which doesn't use the COMPB interrupt?
-
- Posts: 1445
- Joined: Mon Feb 11, 2013 8:08 am
- Location: Brisbane, Australia
Re: Five clock per pixel RLE mode
Sadly I am still having lines drawing where there should not be any (see the yellow engine exhaust and blue line from the nose). More debugging next weekend I guess.
Here is a HEX of that same broken picture if someone wants to see it on real hardware. It is just canned lines for this example so the fault stays visible.
I don't think I can use CompB becuase I would crash into the other interrupts code.
I have one interrupt to end a scanline and one to end a run of pixels.
See below
Here is a HEX of that same broken picture if someone wants to see it on real hardware. It is just canned lines for this example so the fault stays visible.
I don't think I can use CompB becuase I would crash into the other interrupts code.
I have one interrupt to end a scanline and one to end a run of pixels.
See below
Code: Select all
jmp __vector_13 ; TIMER1_COMPA
jmp __vector_14 ; TIMER1_COMPB
; ***************************************
; ******** TIMER1_OVF interrupt *********
; ***************************************
in r3, _SFR_IO_ADDR(SREG) ; Save the status register
movw r4, r30 ; Save the Z register pair because we are about to trash them with the IJMP
ldi ZH, 0x00 ; ZH = 0x00 so the address IJMP goes too is 0x0038, 0x0039, 0x003A or 0x003B, 0x003C
; Get the value of TCNT1 for jitter elimination.
; The overflow interrupt flag gets set at 0x0000 but it takes a variable amount
; of time to get to this point. We need to read the timer value to see how much
; past 0x0000 it made it so we can correct for the variable latency.
lds ZL,_SFR_MEM_ADDR(TCNT1L) ; The lowest value this can be is 0x08 (interrupt latency plus 3 instructions above)
; The highest value it can be is 0x0C
subi ZL, -(0x30) ; Add 0x30 to the TCNT value so it is 0x38..0x3C
ijmp ; Jump to one of 5 instructions in "Jitter_Fixer" (4x NOP and 1x SEI)
nop ; Just a space filling NOP so that the rest of the vectors are aligned
; The next 3 int vectors (TIMER0 COMPA, COMPB and OVF) are unusable
; because the above code uses up their allocated space
; If you enable these interrupts bad things will happen
; This should be no loss as Timer0 in the Uzebox should never need an ISR
;jmp __bad_interrupt ; TIMER0_COMPA
;jmp __bad_interrupt ; TIMER0_COMPB
;jmp __bad_interrupt ; TIMER0_OVF
jmp __bad_interrupt ; SPI_STC
jmp __bad_interrupt ; USART0_RX
jmp __bad_interrupt ; USART0_UDRE
; ***************************************
; ********* USART0_TX interrupt *********
; ***************************************
nop ; waste a clock so the last pixel is correct width
out _SFR_IO_ADDR(PORTC), r2 ; Output a BLACK pixel for the end of the scanline (r2 is ZERO)
rjmp EndScanlineInt
nop
; The next int vector (ANALOG_COMP) is unusable
; because the above code uses up its allocated space
; If you enable this interrupt bad things will happen
;jmp __bad_interrupt ; ANALOG_COMP
jmp __bad_interrupt ; ADC
jmp __bad_interrupt ; EE_READY
- Attachments
-
- 1337.hex
- (32.52 KiB) Downloaded 611 times
Re: Five clock per pixel RLE mode
Very cool, I instantly thought of the original Star Fox when I saw that!
Re: Five clock per pixel RLE mode
Ouch, I see, so it will eventually need resolving UART timing (for adding ESP8266 support as well which needs an UART working like an UART).
But this certainly looks great, wonder how far it could go! You have an entirely different memory budget here compared to the usual. It would be nice to see some vector or 3D stuff eventually!
But this certainly looks great, wonder how far it could go! You have an entirely different memory budget here compared to the usual. It would be nice to see some vector or 3D stuff eventually!
Re: Five clock per pixel RLE mode
Wow, seeing polygons on a Uzebox is very impressive! Any progress coming soon? (I know it's been a year )
-
- Posts: 1445
- Joined: Mon Feb 11, 2013 8:08 am
- Location: Brisbane, Australia
Re: Five clock per pixel RLE mode
Well - there has been progress since this thread. I posted a moving polygon HEX file here
http://uzebox.org/forums/viewtopic.php? ... 402#p30402
About a month after this threads last comment.
http://uzebox.org/forums/viewtopic.php? ... 402#p30402
About a month after this threads last comment.