| A thought (it's Bad *Apple* after all) [message #339077] |
Sat, 11 March 2017 13:19  |
Steve Nickolas
Messages: 2036
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
If anyone's familiar with the demo "8088 Domination", which runs on a
stock IBM 5150 with a hard drive and a sound card, it plays the entire
"Bad Apple" video on the CGA and the sound card...
I wonder if something similar - though perhaps using a synth version of
the song instead of the actual song - might be possible on a IIgs
similarly configured. (It would probably require trickery beyond what I'm
capable of, to get a reasonable framerate. I think the ideal graphics
mode would be the standard Apple ][ 280x192 mode.)
;)
https://www.youtube.com/watch?v=UkgK8eUdpAo
-uso.
|
|
|
|
| Re: A thought (it's Bad *Apple* after all) [message #339096 is a reply to message #339077] |
Sat, 11 March 2017 19:27  |
gids.rs
Messages: 1395
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Saturday, March 11, 2017 at 12:19:37 PM UTC-6, Steve Nickolas wrote:
> If anyone's familiar with the demo "8088 Domination", which runs on a
> stock IBM 5150 with a hard drive and a sound card, it plays the entire
> "Bad Apple" video on the CGA and the sound card...
>
> I wonder if something similar - though perhaps using a synth version of
> the song instead of the actual song - might be possible on a IIgs
> similarly configured. (It would probably require trickery beyond what I'm
> capable of, to get a reasonable framerate. I think the ideal graphics
> mode would be the standard Apple ][ 280x192 mode.)
>
I think it would be simpler than that. Because we are only dealing with black and white, you wouldn't have to animate the entire screen. Just the edges of the sillouette, which would be no more than 3 bytes wide, most times.. This would not only be a lot faster, but it would also save a ton of space in memory and on the hard drive. Reading from a 1 Mb Ram card would probably be most ideal.
For both detail and speed, I also think that dbl-hi-res can do better detail and smoother animation. If hi-res is used in the way in which it can display 580 pixels using the 1/2 pixel shift, then using dbl-hi-res would also be faster.
I am sure I could also write the routine in which 2 screens are compared and only the bytes that are different, are stored. This would all be for the dbl-hi-res screen.
I could also program it to use both dbl-hi-res screens for smoother animation.
|
|
|
|
| Re: A thought (it's Bad *Apple* after all) [message #339099 is a reply to message #339096] |
Sat, 11 March 2017 19:42 |
Steve Nickolas
Messages: 2036
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Sat, 11 Mar 2017, gids.rs@sasktel.net wrote:
> I think it would be simpler than that. Because we are only dealing with
> black and white, you wouldn't have to animate the entire screen. Just
> the edges of the sillouette, which would be no more than 3 bytes wide,
> most times. This would not only be a lot faster, but it would also save
> a ton of space in memory and on the hard drive. Reading from a 1 Mb Ram
> card would probably be most ideal.
The PC demo used a compression scheme too.
> For both detail and speed, I also think that dbl-hi-res can do better
> detail and smoother animation. If hi-res is used in the way in which it
> can display 580 pixels using the 1/2 pixel shift, then using dbl-hi-res
> would also be faster.
Than regular HGR?
> I am sure I could also write the routine in which 2 screens are compared
> and only the bytes that are different, are stored. This would all be
> for the dbl-hi-res screen.
>
> I could also program it to use both dbl-hi-res screens for smoother
> animation.
Also, if one would want to play an AY8910 version of the song through a
Mockingboard (to do it with music on a //e as opposed to a IIgs), that
would eat cycles - could the //e still keep up?
-uso.
|
|
|
|
|
|
| Re: A thought (it's Bad *Apple* after all) [message #339108 is a reply to message #339099] |
Sat, 11 March 2017 22:08 |
gids.rs
Messages: 1395
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Saturday, March 11, 2017 at 6:42:40 PM UTC-6, Steve Nickolas wrote:
> On Sat, 11 Mar 2017, Rob wrote:
>
>> I think it would be simpler than that. Because we are only dealing with
>> black and white, you wouldn't have to animate the entire screen. Just
>> the edges of the sillouette, which would be no more than 3 bytes wide,
>> most times. This would not only be a lot faster, but it would also save
>> a ton of space in memory and on the hard drive. Reading from a 1 Mb Ram
>> card would probably be most ideal.
>
> The PC demo used a compression scheme too.
What I described isn't using compression. It is just storing the bytes that are changing from one screen to the next. With only black and white to deal with makes it very easy as only bytes around the outside of the silhouette need to be changed. The routine I have in mind can make this very easy..
>
>> For both detail and speed, I also think that dbl-hi-res can do better
>> detail and smoother animation. If hi-res is used in the way in which it
>> can display 580 pixels using the 1/2 pixel shift, then using dbl-hi-res
>> would also be faster.
>
> Than regular HGR?
Yes. Storing 3 to 4 bytes on each side of the silhouette and in alternate memory would be faster than the math required to make hi-res do the 1/2 pixel shift.
>
>> I am sure I could also write the routine in which 2 screens are compared
>> and only the bytes that are different, are stored. This would all be
>> for the dbl-hi-res screen.
>>
>> I could also program it to use both dbl-hi-res screens for smoother
>> animation.
>
> Also, if one would want to play an AY8910 version of the song through a
> Mockingboard (to do it with music on a //e as opposed to a IIgs), that
> would eat cycles - could the //e still keep up?
I will try and put something together with the draw routines and let you know how much time is can be spared.
|
|
|
|
| Re: A thought (it's Bad *Apple* after all) [message #339111 is a reply to message #339108] |
Sat, 11 March 2017 23:37 |
Michael J. Mahon
Messages: 1767
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
<gids.rs@sasktel.net> wrote:
> On Saturday, March 11, 2017 at 6:42:40 PM UTC-6, Steve Nickolas wrote:
>> On Sat, 11 Mar 2017, Rob wrote:
>>
>>> I think it would be simpler than that. Because we are only dealing with
>>> black and white, you wouldn't have to animate the entire screen. Just
>>> the edges of the sillouette, which would be no more than 3 bytes wide,
>>> most times. This would not only be a lot faster, but it would also save
>>> a ton of space in memory and on the hard drive. Reading from a 1 Mb Ram
>>> card would probably be most ideal.
>>
>> The PC demo used a compression scheme too.
>
> What I described isn't using compression. It is just storing the bytes
> that are changing from one screen to the next. With only black and white
> to deal with makes it very easy as only bytes around the outside of the
> silhouette need to be changed. The routine I have in mind can make this very easy.
>
>>
>>> For both detail and speed, I also think that dbl-hi-res can do better
>>> detail and smoother animation. If hi-res is used in the way in which it
>>> can display 580 pixels using the 1/2 pixel shift, then using dbl-hi-res
>>> would also be faster.
>>
>> Than regular HGR?
>
> Yes. Storing 3 to 4 bytes on each side of the silhouette and in
> alternate memory would be faster than the math required to make hi-res do
> the 1/2 pixel shift.
It won't take any extra time if you store the whole changed byte(s).
>>
>>> I am sure I could also write the routine in which 2 screens are compared
>>> and only the bytes that are different, are stored. This would all be
>>> for the dbl-hi-res screen.
>>>
>>> I could also program it to use both dbl-hi-res screens for smoother
>>> animation.
>>
>> Also, if one would want to play an AY8910 version of the song through a
>> Mockingboard (to do it with music on a //e as opposed to a IIgs), that
>> would eat cycles - could the //e still keep up?
>
>
> I will try and put something together with the draw routines and let you
> know how much time is can be spared.
>
>
>
--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
|
|
|
|
| Re: A thought (it's Bad *Apple* after all) [message #339115 is a reply to message #339096] |
Sun, 12 March 2017 01:00 |
David Schmenk
Messages: 374
Registered: December 2012
Karma: 0
|
Senior Member |
|
|
On Saturday, 11 March 2017 16:27:28 UTC-8, gid...@sasktel.net wrote:
> On Saturday, March 11, 2017 at 12:19:37 PM UTC-6, Steve Nickolas wrote:
>> If anyone's familiar with the demo "8088 Domination", which runs on a
>> stock IBM 5150 with a hard drive and a sound card, it plays the entire
>> "Bad Apple" video on the CGA and the sound card...
>>
>> I wonder if something similar - though perhaps using a synth version of
>> the song instead of the actual song - might be possible on a IIgs
>> similarly configured. (It would probably require trickery beyond what I'm
>> capable of, to get a reasonable framerate. I think the ideal graphics
>> mode would be the standard Apple ][ 280x192 mode.)
>>
>
>
> I think it would be simpler than that. Because we are only dealing with black and white, you wouldn't have to animate the entire screen. Just the edges of the sillouette, which would be no more than 3 bytes wide, most times. This would not only be a lot faster, but it would also save a ton of space in memory and on the hard drive. Reading from a 1 Mb Ram card would probably be most ideal.
>
> For both detail and speed, I also think that dbl-hi-res can do better detail and smoother animation. If hi-res is used in the way in which it can display 580 pixels using the 1/2 pixel shift, then using dbl-hi-res would also be faster.
>
> I am sure I could also write the routine in which 2 screens are compared and only the bytes that are different, are stored. This would all be for the dbl-hi-res screen.
>
> I could also program it to use both dbl-hi-res screens for smoother animation.
If you are going to target the IIGS, what about using the scan line fill-mode of the super hires 320 mode?
|
|
|
|
| Re: A thought (it's Bad *Apple* after all) [message #339122 is a reply to message #339111] |
Sun, 12 March 2017 04:23 |
gids.rs
Messages: 1395
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
> It won't take any extra time if you store the whole changed byte(s).
I guess come to that I think of it, the work of the half pixel shift is done before hand and saved as part of the animation and would just need to be stored to the screen.
Too bad all emulators don't support the shift.
To be viewable with the most computers and emulators, dbl-hi-res should be the choice.
|
|
|
|
| Re: A thought (it's Bad *Apple* after all) [message #339165 is a reply to message #339115] |
Sun, 12 March 2017 23:11 |
Michael J. Mahon
Messages: 1767
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
David Schmenk <dschmenk@gmail.com> wrote:
> On Saturday, 11 March 2017 16:27:28 UTC-8, gid...@sasktel.net wrote:
>> On Saturday, March 11, 2017 at 12:19:37 PM UTC-6, Steve Nickolas wrote:
>>> If anyone's familiar with the demo "8088 Domination", which runs on a
>>> stock IBM 5150 with a hard drive and a sound card, it plays the entire
>>> "Bad Apple" video on the CGA and the sound card...
>>>
>>> I wonder if something similar - though perhaps using a synth version of
>>> the song instead of the actual song - might be possible on a IIgs
>>> similarly configured. (It would probably require trickery beyond what I'm
>>> capable of, to get a reasonable framerate. I think the ideal graphics
>>> mode would be the standard Apple ][ 280x192 mode.)
>>>
>>
>>
>> I think it would be simpler than that. Because we are only dealing with
>> black and white, you wouldn't have to animate the entire screen. Just
>> the edges of the sillouette, which would be no more than 3 bytes wide,
>> most times. This would not only be a lot faster, but it would also save
>> a ton of space in memory and on the hard drive. Reading from a 1 Mb Ram
>> card would probably be most ideal.
>>
>> For both detail and speed, I also think that dbl-hi-res can do better
>> detail and smoother animation. If hi-res is used in the way in which it
>> can display 580 pixels using the 1/2 pixel shift, then using dbl-hi-res
>> would also be faster.
>>
>> I am sure I could also write the routine in which 2 screens are compared
>> and only the bytes that are different, are stored. This would all be
>> for the dbl-hi-res screen.
>>
>> I could also program it to use both dbl-hi-res screens for smoother animation.
>
> If you are going to target the IIGS, what about using the scan line
> fill-mode of the super hires 320 mode?
>
I agree--that would be a natural fit. Built-in run length coding. ;-)
--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
|
|
|
|
| Re: A thought (it's Bad *Apple* after all) [message #339167 is a reply to message #339122] |
Sun, 12 March 2017 23:11 |
Michael J. Mahon
Messages: 1767
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
<gids.rs@sasktel.net> wrote:
>> It won't take any extra time if you store the whole changed byte(s).
>
>
> I guess come to that I think of it, the work of the half pixel shift is
> done before hand and saved as part of the animation and would just need
> to be stored to the screen.
>
> Too bad all emulators don't support the shift.
>
> To be viewable with the most computers and emulators, dbl-hi-res should be the choice.
>
I also realized that if a, say, white-to-black transition went from one
shift mode to the other, all the preceding bytes would need to be changed
to the same shift mode to avoid a half pixel gap or pile-up near the
boundary. Of course, that would just move the "ragged edge" to the raster's
edge.
I see why DHR would fix these artifacts.
--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
|
|
|
|
| Re: A thought (it's Bad *Apple* after all) [message #340469 is a reply to message #339077] |
Tue, 28 March 2017 03:41 |
gids.rs
Messages: 1395
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Saturday, March 11, 2017 at 12:19:37 PM UTC-6, Steve Nickolas wrote:
> If anyone's familiar with the demo "8088 Domination", which runs on a
> stock IBM 5150 with a hard drive and a sound card, it plays the entire
> "Bad Apple" video on the CGA and the sound card...
>
> I wonder if something similar - though perhaps using a synth version of
> the song instead of the actual song - might be possible on a IIgs
> similarly configured. (It would probably require trickery beyond what I'm
> capable of, to get a reasonable framerate. I think the ideal graphics
> mode would be the standard Apple ][ 280x192 mode.)
>
> ;)
>
> https://www.youtube.com/watch?v=UkgK8eUdpAo
>
> -uso.
I think I have figured out the specifics for a very fast draw routine and a comparison program to change only the bytes that are different between 2 frames of animation.
All that is left is to capture each video frame as a dbl-hi-res 560x192 b/w screen image.
I estimate that 8 bytes max per line need to be stored to the screen to alter the bytes that change from frame to frame. 4 bytes for each side of the silhouette and then another 8 bytes for 2 sets of signal bytes and coordinates.
And because I have implemented an absolute move, not all lines need to be stored. Probably less than half of the lines on the screen have bytes that change from frame to frame, but is even far fewer when the animation gets very small.
So at 16 bytes per line times average of 96 lines is 1536 bytes per frame compared to 16384 bytes for a full screen which is just over a 10 times savings. Which is almost 6 pages of memory for data per frame. Which is 1.5 kb per frame. A 64 kb chunk of memory would then be able to hold almost 43 frames for 3/4 sec. A 1 Mb ram card would allow for just over 12 secs of animation. The Prodos max file size of 16 Mb would be able to play for 16x8 = 192 secs (~3 minutes)
I believe I calculated to the high end of maximum memory, and that no where near the average of 96 lines have bytes that change and probably only 2 bytes on each side of the silhouette would do. I think in the end I could squeeze to closer to 4 minutes for a 16 Mb file size.
The draw routine works something like this:
* this is the draw routine for shadow animation
* signal byte for shadow art movement on mostly black screen
* $80 - hi-bit on means store bytes - lower 7 bits means # of bytes to store
* - has to be a multiple of 2 bytes
- so mostly 2 or 4 bytes each side of silhouette
* $80 - hi-bit off means absolute move - lower 7 bits = x-coord = 0-$4F
* next byte for y-coord; y= 0-$C0 lines on screen
org $9000
sht
lda #$40 ; start of compressed frame data
sta $9
lda #0
sta $8
]lp jsr nxtframe
cpy #$96 ; end of frame data
bcc ]lp
nxtframe lda #0
sta $fe
sta $26
lda #$20
sta $27
ldy #0
sty $ff
]loop jsr gety
lda ($8),y
bpl absolut
and #$7f
tax
]lp jsr gety
lda ($8),y ; get bytes to store direct on screen
pha
ldy $fe
inc $fe
tya
lsr
tay
pla
php
sei
bit $c055 ; always starts on an even byte
sta ($26),y
bit $c054
plp
jsr gety
lda ($8),y
pha
ldy $fe
inc $fe
tya
lsr
tay
pla
sta ($26),y
dex
bne ]lp
beq ]loop ; always
* was put here so it is only checked every 2nd time
absolut sta $fe
jsr gety
lda ($8),y
tay
ora $fe ; x,y coord of 0,0 marks end of frame
beq fini ; finished drawing frame, move on to the next one
chkline cpy $fd
beq ]loop ; still on same line
tya
asl
tay
and #$f0
bpl *+4
ora #5
bcc *+4
ora #$a
asl
asl
sta $26
tya
and #$e
adc #$10
asl $26
rol
sta $27
bne ]loop ; always
fini dey ; the first call is a GETY so will skip the first byte
tya
clc
adc $8
bcc *+4
inc $9
ldy $9
rts
gety inc $ff
bne *+4
inc $9
ldy $ff
rts
|
|
|
|
| Re: A thought (it's Bad *Apple* after all) [message #340470 is a reply to message #339165] |
Tue, 28 March 2017 05:39 |
sicklittlemonkey
Messages: 570
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Monday, 13 March 2017 16:11:47 UTC+13, Michael J. Mahon wrote:
> David Schmenk:
>> If you are going to target the IIGS, what about using the scan line
>> fill-mode of the super hires 320 mode?
>>
>
> I agree--that would be a natural fit. Built-in run length coding. ;-)
That was my first thought too, however this video does use grayscale in parts. I suppose it would need to be converted to B&W in the non-GS case anyway.
Cheers,
Nick.
|
|
|
|
|
|
|
|
| Re: A thought (it's Bad *Apple* after all) [message #340575 is a reply to message #340485] |
Tue, 28 March 2017 20:41 |
sicklittlemonkey
Messages: 570
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Tuesday, 28 March 2017 23:48:58 UTC+13, Steve Nickolas wrote:
>> The competition.
>> https://www.youtube.com/watch?v=MWdG413nNkI
>>
>> Cheers,
>> Nick.
>
> 8088 Domination is where I first heard of Bad Apple. :P
Yes, you mentioned it, and if anyone does something similar on the Apple II it will inevitably be compared to it.
Since I've never seen it (or heard of it) I suspect others might want to have a look too.
It's impressive - only the IIgs could do it justice, IMO. ; - )
Cheers,
Nick.
|
|
|
|
| Re: A thought (it's Bad *Apple* after all) [message #340757 is a reply to message #339108] |
Thu, 30 March 2017 18:21 |
BLuRry
Messages: 489
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Saturday, March 11, 2017 at 9:08:54 PM UTC-6, gid...@sasktel.net wrote:
> On Saturday, March 11, 2017 at 6:42:40 PM UTC-6, Steve Nickolas wrote:
>> On Sat, 11 Mar 2017, Rob wrote:
>>
>>> I think it would be simpler than that. Because we are only dealing with
>>> black and white, you wouldn't have to animate the entire screen. Just
>>> the edges of the sillouette, which would be no more than 3 bytes wide,
>>> most times. This would not only be a lot faster, but it would also save
>>> a ton of space in memory and on the hard drive. Reading from a 1 Mb Ram
>>> card would probably be most ideal.
>>
>> The PC demo used a compression scheme too.
>
> What I described isn't using compression. It is just storing the bytes that are changing from one screen to the next. With only black and white to deal with makes it very easy as only bytes around the outside of the silhouette need to be changed. The routine I have in mind can make this very easy.
That's called delta compression. :) Anyway, I have code for it here:
Line 500: Send compressed data
https://sourceforge.net/p/a2gameserver/code/HEAD/tree/a2game server/src/ags/communication/TransferHost.java
It's a little weird with delays because it's meant to wait for the Apple reading the data over a live serial feed. If running off of slinky ram the pauses in the code are not necessary but you could convert them to calculate decompression timing.
The BufferedDisplay calls the compression if it's enabled (line 45) and also manages two copies of the screen (page1, page2) such that the delta calculations are made per page allowing flicker-free animation.
https://sourceforge.net/p/a2gameserver/code/HEAD/tree/a2game server/src/ags/ui/HiresBufferedScreen.java
And the decompression code is here:
https://sourceforge.net/p/a2gameserver/code/HEAD/tree/a2game server/src/ags/asm/compression/deflate_main.a?force=True
There's a XOR mode which is toggled as needed by the compressor (based on if it thinks it is faster to do so.) This toggles between delta (XOR) or non-delta (store-only).
>
>>
>>> For both detail and speed, I also think that dbl-hi-res can do better
>>> detail and smoother animation. If hi-res is used in the way in which it
>>> can display 580 pixels using the 1/2 pixel shift, then using dbl-hi-res
>>> would also be faster.
>>
>> Than regular HGR?
>
> Yes. Storing 3 to 4 bytes on each side of the silhouette and in alternate memory would be faster than the math required to make hi-res do the 1/2 pixel shift.
>
>>
>>> I am sure I could also write the routine in which 2 screens are compared
>>> and only the bytes that are different, are stored. This would all be
>>> for the dbl-hi-res screen.
>>>
>>> I could also program it to use both dbl-hi-res screens for smoother
>>> animation.
>>
>> Also, if one would want to play an AY8910 version of the song through a
>> Mockingboard (to do it with music on a //e as opposed to a IIgs), that
>> would eat cycles - could the //e still keep up?
>
>
> I will try and put something together with the draw routines and let you know how much time is can be spared.
|
|
|
|
| Re: A thought (it's Bad *Apple* after all) [message #340758 is a reply to message #340757] |
Thu, 30 March 2017 18:29 |
Steve Nickolas
Messages: 2036
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Thu, 30 Mar 2017, BLuRry wrote:
> On Saturday, March 11, 2017 at 9:08:54 PM UTC-6, gid...@sasktel.net wrote:
>>
>> What I described isn't using compression. It is just storing the bytes that are changing from one screen to the next. With only black and white to deal with makes it very easy as only bytes around the outside of the silhouette need to be changed. The routine I have in mind can make this very easy.
>
> That's called delta compression. :)
That's basically what the PC version does, right? That's the very trick
the PC version used, iirc, to get the necessary kind of speed on a 4.77
MHz 8088.
-uso.
|
|
|
|
Members
Search
Help
Register
Login
Home
