Raycasting 3D demo disk

[David Schmenk]

Here for your enjoyment is a technology preview/demonstration of a
raycasting and rendering algorithm I have developed as part of my Apple
II 30th birthday-retro-game-just-because-I-can thing. Reminiscent of
Wolfenstein 3D, it runs on a standard 1 MHz 48K Apple II+ (or II w/
Applesoft in RAM/ROM) or greater. Only a joystick is required. It is
possible to run it on an emulator, but I highly recommend using real
hardware with a color monitor. Accelerators make it run too fast, so
disable them if you want the controls to be sane. I present it as a
140K DOS 3.3 disk image compressed with gzip. Download with this URL:

http://schmenk.is-a-geek.com/tarfiles/raydemo.dsk.gz

I hope it doesn't end up being a bad idea placing a direct link, but its
only 11K in size.

Just a little background - I have a pile of algorithms I've been
creating in my notebook for some time. Some people like Soduku for
their diversion, I like 6502 assembly language. The 30th anniversary of
the Apple II seemed like a good time to put some of them together. Its
always fun to make old (obsolete) hardware do things people don't
expect. In this case, a full screen 3D walkthrough. However, don't
think I've made an Apple II perform like NVIDIA's latest GPU. In order
to get interactive framerates and decent colors, the lo-res graphics
mode is employed. I am not double buffering the rendering - you see it
as it renders. Textures are only 16x16, and there are only 15 of them.
It would have seemed pretty cool back in 1977 though.

Download it, give it a try, let me know what you think. I hope to have
an actual game to play with a geekly humorous story-line in a few months
based on this technology.

Dave...

[mdj]

David Schmenk wrote:

> Download it, give it a try, let me know what you think. I hope to have
> an actual game to play with a geekly humorous story-line in a few months
> based on this technology.

Very nice! The framerate is astonishingly good - I wonder how it would
handle 80x48 :-)

I look forward to your game - this is the nicest "push the ole Apple II
to new limits" hack I've seen for a while.

Matt

[heuser...@freenet.de]

David Schmenk schrieb:

>
> Download it, give it a try, let me know what you think. I hope to
> have an actual game to play with a geekly humorous story-line
> in a few months based on this technology.

This is great stuff! Pretty fast and "clean" texturing.
The textures looks good, too!

And not to forget: The movement control with a joystick works
very well with a capital "V" - I had no problems with AppleWin
and a decent game pad.

For a game, however, double buffering while not essential could
IMHO give an even better result.

And an optional double-lores mode, as Matt said, would be terrific.

Yeah, I know - just out of the door and those nerds demand more!

;-)

bye
Marcus

[David Schmenk]

Thanks for the feedback. As this is a 30th anniversary game for the
Apple II, II+, 80 x 48 will have to wait until 2013 :-) Honestly, there
is much game logic and more sprite graphics to add which will impact the
framerate a great deal. I hope it remains playable once that is done.

Dave...

[David Schmenk]

heuser...@freenet.de wrote:
> David Schmenk schrieb:
>> Download it, give it a try, let me know what you think. I hope to
>> have an actual game to play with a geekly humorous story-line
>> in a few months based on this technology.
>
> This is great stuff! Pretty fast and "clean" texturing.
> The textures looks good, too!

Especially if you stand back and squint!

>
> And not to forget: The movement control with a joystick works
> very well with a capital "V" - I had no problems with AppleWin
> and a decent game pad.
>
> For a game, however, double buffering while not essential could
> IMHO give an even better result.
>

Indeed. This is a demo for the technology. It will be double buffered
in the real implementation, but sometimes I like to see what is going
on. No smoke and mirrors. (well, maybe a little)

> And an optional double-lores mode, as Matt said, would be terrific.
>

2013 :-)

> Yeah, I know - just out of the door and those nerds demand more!
>
> ;-)
>
> bye
> Marcus
>

Thanks,

Dave...

[aiia...@gmail.com]

David Schmenk wrote:
> Here for your enjoyment

Thank you! Very cool!

> I hope it doesn't end up being a bad idea placing a direct link, but its
> only 11K in size.

windows 2000 had a bit of trouble opening the GZ, but I got it.

>
> However, don't
> think I've made an Apple II perform like NVIDIA's latest GPU.

You made a "playable" walk around in 3d simulation!...

> In order
> to get interactive framerates and decent colors, the lo-res graphics
> mode is employed. I am not double buffering the rendering - you see it
> as it renders. Textures are only 16x16, and there are only 15 of them.
> It would have seemed pretty cool back in 1977 though.

I think it would be cool to put it on hires screen, in a 40X24 window
in the
center...

\\> Download it, give it a try, let me know what you think. I hope to

have
> an actual game to play with a geekly humorous story-line in a few months
> based on this technology.

what I think: it's amazing to see an apple II do this.. reminds me of
the excitement of playing Wolf3d on the GS a few years ago..

Thanks for sharing.. I'm impressed, and I'm sure anyone who has
ever used an apple II would be impressed!

Rich

[aiia...@gmail.com]

David Schmenk wrote:
> Here for your enjoyment is a technology preview/demonstration of a
> raycasting and rendering algorithm I have developed

You might want to contact Blurry, at
http://brendan.robert.googlepages.com/

who released a similar demo in the past ?year?

Rich

[aiia...@gmail.com]

aiiad...@gmail.com wrote:
> You might want to contact Blurry, at
> http://brendan.robert.googlepages.com/

His 3d demo (in lores) was in the "other"
section in the small frame on the page,
but the "other" page is broken now..

Rich

[David Schmenk]

aiia...@gmail.com wrote:
> David Schmenk wrote:
>> Here for your enjoyment
>
> Thank you! Very cool!
>
>
>

>> In order
>> to get interactive framerates and decent colors, the lo-res graphics
>> mode is employed. I am not double buffering the rendering - you see it
>> as it renders. Textures are only 16x16, and there are only 15 of them.
>> It would have seemed pretty cool back in 1977 though.
>
> I think it would be cool to put it on hires screen, in a 40X24 window
> in the
> center...
>

While deciding on the graphics mode, I did consider the hires screen.
However the lores mode has distinct advantages. Full screen and more
colors make for a more immersive feel. The thing I didn't like about
Wold3D was the tiny window in the middle. My feel is a full screen with
fast framerate can offset the blocky pixels. I just have to take off my
glasses and I can't tell the difference between lores and hires :-)

>
> \\> Download it, give it a try, let me know what you think. I hope to
> have
>> an actual game to play with a geekly humorous story-line in a few months
>> based on this technology.
>
> what I think: it's amazing to see an apple II do this.. reminds me of
> the excitement of playing Wolf3d on the GS a few years ago..
>
> Thanks for sharing.. I'm impressed, and I'm sure anyone who has
> ever used an apple II would be impressed!
>
>
> Rich
>

Thanks,

Dave...

[aiia...@gmail.com]

David Schmenk wrote:
>Honestly, there
>is much game logic and more sprite graphics to add which will impact the
>framerate a great deal. I hope it remains playable once that is done

one way to speed it up is to stop relying on joystick for input, it
1)discharges a cap
2)charges a cap, and increments a counter

the joystick routine takes more/less cycles depending
on the current stick position..

there is an article on the net to easily interface a NES
control pad to the gameport.. then you get digital information
and it takes less time..

Rich

[David Schmenk]

One of my previous excursions into improving joystick reading
performance resulted in an algorithm to read both axis simultaneously
while outputing sound. This is used in the raycaster demo. I didn't
add any tones so it is currently quiet. The advantage is that it is
constant time to read the joysticks, regardless of position. The
downside is the accuracy is reduced to a range 0..63 instead of the
usual 0..255. Using the keyboard isn't practical on pre-IIe keyboards
and requiring a special built joystick interface isn't a viable option.
There are many areas in the final code that I am sure will be a
greater cause of slowness. Only time will tell.

Dave...

[aiia...@gmail.com]

David Schmenk wrote:
> One of my previous excursions into improving joystick reading
> performance resulted in an algorithm to read both axis simultaneously
> while outputing sound.

I see.. I was wondering what that was when I was looking over
the disassembly...

Rich

[aiia...@gmail.com]

heuser...@freenet.de wrote:
> This is great stuff! Pretty fast and "clean" texturing.
> The textures looks good, too!
>

HERE IS A TEXTURE EDITOR FOR HIS DEMO :-)

out of emu.. s)ave then type DEMO.TEX to update
the demo texture file

the assembly at the end is to make high nibble match
low nibble..

10 GR
80 GOSUB 12000
90 GOSUB 10000
100 VTAB 21: PRINT "TEXTURE# = ";T + 1;" ";
110 VTAB 21: HTAB 16: PRINT "COLOR= ";C;" A=+ Z=-"
8000 GET A$
8010 IF A$ = "." THEN T = T + 1: GOSUB 13000
8020 IF A$ = "," THEN T = T - 1: GOSUB 13000
8040 VTAB 21: PRINT "TEXTURE# = ";T + 1;" ";
8050 IF A$ = "Q" THEN STOP
8060 IF A$ = "J" THEN JX = JX - 1
8070 IF A$ = "L" THEN JX = JX + 1
8080 IF A$ = "I" THEN JY = JY - 1
8090 IF A$ = "K" THEN JY = JY + 1
8091 IF JY > 16 THEN JY = 16
8092 IF JX > 16 THEN JX = 16
8093 IF JX < 1 THEN JX = 1
8094 IF JY < 1 THEN JY = 1
8100 IF JY < > OY OR JX < > OX THEN COLOR= OC: PLOT OX,OY: COLOR=
C:OY = JY:OX = JX:OC = SCRN( JX,JY): PLOT JX,JY
8101 IF A$ = "Z" OR A$ = "A" THEN GOSUB 20000
8110 IF A$ = " " THEN GOSUB 30000
8120 COLOR= C
8130 VTAB 21: HTAB 16: PRINT "COLOR= ";C
8150 D = 16384 + (T * 256) + ((JX - 1) * 16) + (JY - 1)
8170 IF A$ = "S" THEN VTAB 22: INPUT "NAME ";A$: PRINT CHR$
(4);"BSAVE ";A$;",A$4000,L4096": GOTO 100
9000 GOTO 8000
10000 REM
10010 T = 0: REM WHICH TEXTURE
10020 PRINT CHR$ (4);"BLOAD DEMO.TEX,A$4000"
10021 PRINT CHR$ (4);"BLOAD ROL,A$300"
10025 C = 5
10030 JX = 8:JY = 8
10040 OX = JX:OY = JY:OC = SCRN( OX,OY)
10045 COLOR= C: PLOT JX,JY
10050 HOME
10055 VTAB 22: PRINT " I MOVE <SPC>=PLOT <=NEXT TEXTURE"
10056 VTAB 23: PRINT "JKL S=AVE Q=IT >=PREV TEXTURE"
10060 COLOR= 1: HLIN 0,17 AT 17
10070 HLIN 0,17 AT 0
10080 VLIN 0,17 AT 0
10090 VLIN 0,17 AT 17
10100 RETURN
12000 IF T < 0 THEN T = 0
12005 IF T > 15 THEN T = 15
12009 FOR Y = 1 TO 16
12010 FOR X = 1 TO 16
12020 B = 16384 + (T * 256) + ((Y - 1) * 16) + (X - 1)
12030 A = PEEK (B)
12040 COLOR= A
12050 PLOT Y,X
12060 NEXT X
12070 NEXT Y
12080 RETURN
13000 GOSUB 12000
13010 OC = SCRN( JX,JY)
13020 COLOR= C: PLOT JX,JY
13030 RETURN
20000 REM COLOR CHANGE
20010 IF A$ = "Z" THEN C = C - 1
20020 IF A$ = "A" THEN C = C + 1
20030 IF C < 0 THEN C = 0
20040 IF C > 15 THEN C = 15
20050 COLOR= C
20060 VTAB 21: HTAB 16: PRINT "COLOR= ";C;" ";
20070 PLOT 22,39
20080 PLOT JX,JY
20090 RETURN
30000 REM POKE PIXEL
30010 D = 16384 + (T * 256) + ((JX - 1) * 16) + (JY - 1)
30020 POKE 768,C: CALL 769:
30030 PIX = PEEK (768)
30040 POKE D,PIX
30050 OC = C
30060 RETURN

ooh yeah and some assembly...

type call -151
*

type ! (or F666g on older apples)
!

!301: lda 300
! rol
! rol
! rol
! rol
! ora 300
! sta 300
! rts
! <return key>
*

<press control C><return>
]

type:

bsave rol,a$300,L17

Rich

[Michael J. Mahon]

If all that's needed is a digital up/center/down, right/center/left
indication, then it's not necessary to keep polling the joystick
inputs.

You can trigger them, then test twice at the "boundary times" between
the left/center and center/right zones (similarly for up/center/down).
If you keep track of elapsed time to pick the right times to check,
no other polls need to be done.

After the later of the two intervals, you can do things without
keeping further track of time.

-michael

NadaNet networking for Apple II computers!
Home page: http://members.aol.com/MJMahon/

"The wastebasket is our most important design
tool--and it's seriously underused."

[Michael J. Mahon]

And even if you are polling, you never have to poll beyond the
"latest" boundary--like center/right or center/down. As soon as
you reach that point, you don't care when the input flips, since
you already know what the three-valued result is.

[aiia...@gmail.com]

David Schmenk wrote:
> Here for your enjoyment is a technology preview/demonstration of a
> raycasting and rendering algorithm

here is a texture/ "tile" editor, as well as MAP editor...

RUN it, press 1 to go to demo...

ESC from demo back to the editor...

press 2 to go to map editor

map editor:

JKLI move, a for texture up, z for texture down
control J to change vertical to current texture

control I to change horizontal to current texture

<return> to set player position to current cursor position

<escape> to return to tex editor

Rich

10 GR
20 D$ = CHR$ (4)
30 PRINT D$;"BLOAD DEMO.OBJ"
40 PRINT D$;"BLOAD DEMO.MAP,A$2000"
50 POKE 768 + 0,0: POKE 768 + 1,32: POKE 768 + 2,32: REM
MAP POINTER & DIMENSION
60 POKE 768 + 6,0: POKE 768 + 7,64: REM TEXTURE MAP BASE
70 POKE 768 + 8,0: POKE 768 + 9,0: REM PLAYER X POS
71 POKE 768 + 10,0: POKE 768 + 11,0: REM PLAYER Y POS
72 POKE 768 + 12,0: REM PLAYER VIEW DIRECTION

80 GOSUB 12000
90 GOSUB 10000
100 VTAB 21: PRINT "TEXTURE# = ";T + 1;" ";
110 VTAB 21: HTAB 16: PRINT "COLOR= ";C;" A=+ Z=-"

4006 LA = 32784
8000 GET A$
8005 IF A$ = "1" THEN GOSUB 11000
8006 IF A$ = "2" THEN GOSUB 40000: POKE 49238,0

10021 PRINT CHR$ (4);"BLOAD ROL,A$8000"

10025 C = 5
10030 JX = 8:JY = 8
10040 OX = JX:OY = JY:OC = SCRN( OX,OY)
10045 COLOR= C: PLOT JX,JY
10050 HOME
10055 VTAB 22: PRINT " I MOVE <SPC>=PLOT <=NEXT TEXTURE"
10056 VTAB 23: PRINT "JKL S=AVE Q=IT >=PREV TEXTURE"
10060 COLOR= 1: HLIN 0,17 AT 17
10070 HLIN 0,17 AT 0
10080 VLIN 0,17 AT 0
10090 VLIN 0,17 AT 17
10100 RETURN

11000 REM GOTO GAME
11010 CALL 24576
11020 GR : GOSUB 10030
11030 GOSUB 13000
11040 RETURN

30020 POKE 32768,C: CALL 32769
30030 PIX = PEEK (32768)

30040 POKE D,PIX
30050 OC = C
30060 RETURN

40000 HGR
40001 GD = 4: REM GRID SIZE
40002 HCOLOR= 7
40005 PRINT CHR$ (4);"BLOAD DEMO.MAP,A$8030"
40006 LD = 32816
40010 FOR Y = 0 TO PEEK (768 + 2) - 1
40020 FOR X = 0 TO PEEK (768 + 2) - 1
40030 W1 = PEEK (768 + 2)
40060 W = LD + (Y * W1) + (X)
40070 D = PEEK (W)
40080 POKE 32768,D
40090 CALL 32786
40095 REM LOW NIBBLE = HORIZ
40100 IF PEEK (32768) > 0 THEN HPLOT X * GD,Y * GD TO (X * GD),(Y *
GD) + GD
40200 POKE 32768,D
40210 CALL 32798
40215 REM HIGH NIBBLE = VERT
40220 IF PEEK (32768) > 0 THEN HPLOT X * GD,Y * GD TO (X * GD) +
GD,Y * GD
40230 NEXT X
40240 NEXT Y
40250 W1 = W1 - 1
40300 EX = 0:EY = 0
40500 HCOLOR= 7:X2 = (EX * GD):Y2 = EY * GD:W4 = GD - 1: HPLOT X2 +
1,Y2 + 1 TO X2 + W4,Y2 + 1 TO X2 + W4,Y2 + W4 TO X2 + 1,Y2 + W4 TO X2 +
1,Y2 + 1:X1 = EX:Y1 = EY
40505 X1 = EX:Y1 = EY
40510 GET A$
40511 IF A$ = "A" THEN TN = TN + 1: IF TN > 15 THEN TN = 0
40512 IF A$ = "Z" THEN TN = TN - 1: IF TN < 0 THEN TN = 15
40513 VTAB 21: HTAB 1: PRINT "TEXTURE= ";TN;" "
40515 IF A$ = CHR$ (13) THEN POKE 768 + 9,EX: POKE 768 + 11,EY
40520 IF A$ = "J" THEN EX = EX - 1
40525 IF A$ = "L" THEN EX = EX + 1
40526 IF A$ = "I" THEN EY = EY - 1
40527 IF A$ = "K" THEN EY = EY + 1
40528 IF ASC (A$) = 27 THEN PRINT CHR$ (4);"BLOAD
DEMO.MAP,A$2000": RETURN
40530 R = ASC (A$): IF R = 9 OR R = 10 THEN GOSUB 40900
40536 IF A$ = "Q" THEN STOP
40538 IF A$ = "S" THEN VTAB 21: INPUT "NAME ";A$: PRINT CHR$
(4);"BSAVE ";A$;",A";LD;",L";( PEEK (768 + 2) * PEEK (768 + 2))
40540 IF EX < 0 THEN EX = W1
40545 IF EX > W1 THEN EX = 0
40550 IF EY < 0 THEN EY = W1
40555 IF EY > W1 THEN EY = 0
40560 IF EX < > X1 OR EY < > Y1 THEN HCOLOR= 0:X3 = (X1 * GD):X3 =
Y1 * GD:W4 = GD - 1: HPLOT X3 + 1,Y2 + 1 TO X2 + W4,Y2 + 1 TO X2 +
W4,Y2 + W4 TO X2 + 1,Y2 + W4 TO X2 + 1,Y2 + 1:X1 = EX:Y1 = EY: GOTO
40500
40600 GOTO 40510
40900 REM EDIT ITEM
40910 W1 = PEEK (768 + 2)
40912 W = LD + (EY * W1) + (EX)
40914 D = PEEK (W)
40916 POKE 32768,D
40918 CALL 32786
40920 REM LOW NIBBLE = HORIZ
40921 L1 = PEEK (32768)
40922 POKE 32768,D
40924 CALL 32798
40926 REM HIGH NIBBLE = VERT
40928 H1 = PEEK (32768)
40930 IF R = 9 THEN GOTO 40940
40931 REM HORIZ
40932 D = H1 + TN
40934 IF TN = 0 THEN HCOLOR= 0: HPLOT EX * GD,EY * GD TO (EX *
GD),(EY * GD) + GD
40936 IF TN > 0 THEN HCOLOR= 7: HPLOT EX * GD,EY * GD TO (EX *
GD),(EY * GD) + GD
40937 POKE W,D
40938 RETURN
40940 REM VERT
40942 D = L1 + (TN * 16)
40944 IF TN = 0 THEN HCOLOR= 0: HPLOT EX * GD,EY * GD TO (EX * GD) +
GD,EY * GD
40946 IF TN > 0 THEN HCOLOR= 7: HPLOT EX * GD,EY * GD TO (EX * GD) +
GD,EY * GD
40947 POKE W,D
40948 RETURN

8000- 20 AD 00 JSR $00AD
8003- 80 2A BRA $802F
8005- 2A ROL
8006- 2A ROL
8007- 2A ROL
8008- 0D 00 80 ORA $8000
800B- 8D 00 80 STA $8000
800E- 60 RTS
800F- EA NOP
8010- EA NOP
8011- EA NOP
8012- AD 00 80 LDA $8000
8015- 29 0F AND #$0F
8017- 8D 00 80 STA $8000
801A- 60 RTS
801B- EA NOP
801C- EA NOP
801D- EA NOP
801E- AD 00 80 LDA $8000
8021- 29 F0 AND #$F0
8023- 8D 00 80 STA $8000
8026- 60 RTS
8027- 00 BRK

[Jerry]

aiia...@gmail.com wrote:

> HERE IS A TEXTURE EDITOR FOR HIS DEMO :-)

Cool, Rich!

> out of emu.. s)ave then type DEMO.TEX to update
> the demo texture file
>
> the assembly at the end is to make high nibble match
> low nibble..

for that, why not just compute PIX= C * 17 ?

[aiia...@gmail.com]

Jerry wrote:
> for that, why not just compute PIX= C * 17 ?

there are 3 routines in the assembly,

1)AND with #$0F (to strip high nibble, leave low nibble)
2)AND with #$F0 (to strip low nibble, leave high nibble)
3)match high nibble to low nibble (lda 8000, ROLX4, ORA 8000)

could all be done with applesoft.. but I'm going to be converting
the map display and texture display code to assembly today,
so I figured I might as well start thinking 6502

Rich

[aiia...@gmail.com]

aiia...@gmail.com wrote:
> David Schmenk wrote:
> > Here for your enjoyment is a technology preview/demonstration of a
> > raycasting and rendering algorithm
>
> here is a texture/ "tile" editor, as well as MAP editor...
>

fix the cursor!
It was erasing incorrectly:

40560 IF EX < > X1 OR EY < > Y1 THEN HCOLOR= 0:X3 = (X1 * GD):Y3 =
Y1 * GD:W4 = GD - 1: HPLOT X3 + 1,Y3 + 1 TO X3 + W4,Y3 + 1 TO X3 +
W4,Y3 + W4 TO X3 + 1,Y3 + W4 TO X3 + 1,Y3 + 1:X1 = EX:Y1 = EY: GOTO
40500

[aiia...@gmail.com]

aiia...@gmail.com wrote:
> David Schmenk wrote:
> > Here for your enjoyment is a technology preview/demonstration of a
> > raycasting and rendering algorithm
>
> here is a texture/ "tile" editor, as well as MAP editor...

the map editor now shows doors on the hires viewer...

email me if you'd like it.

Rich

[Liam Busey]

David Schmenk wrote:
> Here for your enjoyment is a technology preview/demonstration of a
> raycasting and rendering algorithm I have developed as part of my Apple
> II 30th birthday-retro-game-just-because-I-can thing. Reminiscent of
> Wolfenstein 3D, it runs on a standard 1 MHz 48K Apple II+ (or II w/
> Applesoft in RAM/ROM) or greater. Only a joystick is required. It is
> possible to run it on an emulator, but I highly recommend using real
> hardware with a color monitor. Accelerators make it run too fast, so
> disable them if you want the controls to be sane. I present it as a
> 140K DOS 3.3 disk image compressed with gzip. Download with this URL:
>
> http://schmenk.is-a-geek.com/tarfiles/raydemo.dsk.gz

-snip-

That's pretty cool! I fired your demo up on my II+ and it ran great. It
was surprisingly smooth. Lores is normally boring but you really
brought it too life. David Schmenk is definately a geek! ;)

I'll look forward to your improvements as they come along. Nice job.

- Liam Busey

[David Schmenk]

Thanks! Lores definitely is under-appreciated. The texture artwork is
what will make or break the 3D feel of the rendered scene. I tried a
few different ideas, but horizontal details work much better than
vertical details. I did have to add vertical details on the wall
boundaries or else it all blended together.

Dave...

[aiia...@gmail.com]

David Schmenk wrote:
> I did have to add vertical details on the wall
> boundaries or else it all blended together.
>
> Dave...

for sure... you have to have some difference
in color otherwise it's all just one color :-)

You said textures are 16X16, with high nibble
matching low nibble.. If I don't make high
nibble = low nibble, it shows textures are
16X16 bytes, but hi/lo nibbles represent
1 pixel on top of another!... error in the tex
editor showed me this, I was setting the byte
to 1 to 16, not $00,11,22,33,44,55 etc... and
I was getting black spots all over the place :-)

so, if I change the tex editor to display the 16X16
byte as a 16X32 graphic, and allow editing
the hi/lobytes individually, you could get better
resolution.. I don't know if the colors would be
predictable though...

Rich

[David Schmenk]

The colors are replicated in the high and low nibble to avoid shifting
during the rendering loop. Shifting by 4 is the worst case scenario
for the 6502. I already had to unroll the rendering loop for every
vertical pixel to get it fast enough. It still needs to be faster but
having only one general purpose register makes things tough. Take a
look at the memory map for lores to figure out why :-)

Dave...

[aiia...@gmail.com]

David Schmenk wrote:
> Here for your enjoyment is a technology preview/demonstration of a
> raycasting and rendering algorithm I have developed

> Download it, give it a try, let me know what you think. I hope to have
> an actual game to play with a geekly humorous story-line in a few months
> based on this technology.

ideas:

1) half height textures, so you could have tables, countertops, sinks,
etc. they are only 8 cells high, so you can see over the top of them

2) a "see through" color... so you could see through windows into
other rooms.. use one of the colors that are most like another..

3)an "outside" mode.. where you could draw buildings, and they
don't stop at the ceiling, instead they copy the texture to the
next block up, on top of the first tex

4) allow different tex to be exits.. so you could have an "EXIT"
door, as well as "stairs"... when you go up to them, they
RTS to basic.. then basic could look at the coordinates of
the player, and decide where the door or stairs lead.

Rich

[David Schmenk]

Ah, now you've come to the limitations of the 2 1/2 D raycasting and
entered the world of much more sophisticated raycasting. This is the
jump John Carmack made from Wolfenstein 3D to Doom. And the appropriate
jump in processing power to pull it off. My demo, and Wolf3D, only cast
rays in 2D. There is no concept of height or transparency, only
collisions and distance.

As for your suggestions #4, I thought of elevator doors that could take
you to the next and previous levels, but the idea is the same. You will
see that in the real version.

BTW, I have made a decision to change the tools I use to build with.
Originally I was going to keep it all self-hosted on an Apple II using
Merlin. This demo pretty much maxed out my patience with that approach.
I actually had to delete some comments in order to build the object
file without running out of memory. I would have to resort to disk
swapping the source to build anything bigger. Not gonna happen. So I'm
switching to the cc65 assembler/linker tools and build under OS X. I
might put a disk image with the current source and tools I used for the
demo out there if there was any interest.

Dave...

[aiia...@gmail.com]

David Schmenk wrote:

> aiia...@gmail.com wrote:
> >
> > ideas:
> >
> > 1) half height textures, so you could have tables, countertops, sinks,
> > etc. they are only 8 cells high, so you can see over the top of them
> >
> > 2) a "see through" color... so you could see through windows into
> > other rooms.. use one of the colors that are most like another..
> >
> > 3)an "outside" mode.. where you could draw buildings, and they
> > don't stop at the ceiling, instead they copy the texture to the
> > next block up, on top of the first tex
> >
> > 4) allow different tex to be exits.. so you could have an "EXIT"
> > door, as well as "stairs"... when you go up to them, they
> > RTS to basic.. then basic could look at the coordinates of
> > the player, and decide where the door or stairs lead.
> >
> > Rich
> >
>
> Ah, now you've come to the limitations of the 2 1/2 D raycasting and
> entered the world of much more sophisticated raycasting. This is the
> jump John Carmack made from Wolfenstein 3D to Doom. And the appropriate
> jump in processing power to pull it off. My demo, and Wolf3D, only cast
> rays in 2D. There is no concept of height or transparency, only
> collisions and distance.

would #3 work? draw the ceiling, THEN copy already drawn texture
to top of the current one? so the next level up is always the same
as the one below it?

>
> As for your suggestions #4, I thought of elevator doors that could take
> you to the next and previous levels, but the idea is the same. You will
> see that in the real version.

elevator, stairs.. both work.. it could be just a pit to jump down
:-)
it would be cool if more than 1 texture would return to BASIC.. so
there
could be a door next to an elevator.. the door exits to the next map,
the elevator exits to the next floor..

>
> BTW, I have made a decision to change the tools I use to build with.
> Originally I was going to keep it all self-hosted on an Apple II using
> Merlin. This demo pretty much maxed out my patience with that approach.
> I actually had to delete some comments in order to build the object
> file without running out of memory. I would have to resort to disk
> swapping the source to build anything bigger. Not gonna happen. So I'm
> switching to the cc65 assembler/linker tools and build under OS X. I
> might put a disk image with the current source and tools I used for the
> demo out there if there was any interest.

waves hands in air.. "me! please send it to me"

you'll get your code to assemble in seconds instead of minutes with
the CC65 setup..

you could also use an emulator with your favorite assembler.. I've
assembled
programs up to 10k with Merlin8

Rich

[roughana]

aiia...@gmail.com wrote:
> you'll get your code to assemble in seconds instead of minutes with
> the CC65 setup..
>
> you could also use an emulator with your favorite assembler.. I've
> assembled
> programs up to 10k with Merlin8

If you are going to use an emulator to assist with writing code then
don't overlook running Merlin16 on Bernie.
It's fast.

Cheers,
Andrew

[BLuRry]

Yeah, some turd started trying to play "guess the password" with
various remote access ports in my home network, so I shut off all port
forwards until they get a life and find something better to do. This
unfortunately included taking the apache server that hosted part of my
homepage offline as well.

Wow, is all I can say. I started implementing a raycaster using lo-res
as well, as Rich said -- and had gotten stalled because of logical
clipping errors (which junked up display from time to time). However,
I can say you completely blew my experiment out of the water. Great
stuff!!! I was hoping for my own endeavor to add tile support, but was
assuming it was completely impossible to do while maintaining a decent
framerate. And not only did you manage a decent framerate but also
JOYSTICK support! :-O Crazy. Can you make //e keyboard support
configurable so that joystick support can be disabled to save some
cycles?

My only recommendation is to go with little/no sound to save cycles and
use an interrupt-driven mockingboard routine for music/sfx later on.
I've written one and now that a2gameserver is stable can test it with
my //e for whenever you feel you want a copy. Maybe you can pause
playback for incidental SFX like "THWACK!" if the person smacks
face-first into a wall (and Mahon's DAC522 would be a great candidate
for crystal-clear SFX). Otherwise, I think playability would be more
easily maintained if you had wider rooms, since the tight corners make
it a little tricky to move around. But who am I to complain? This
thing ROX!

Also, look for "Way Out" by Sirius software. Sometimes it's attributed
to the cracker "Aldo Reset" who took their name off of the title like a
true punk. If you can't find it, I'll gladly send a disk image your
way.

Great stuff!

[aiia...@gmail.com]

BLuRry wrote:
> Otherwise, I think playability would be more
> easily maintained if you had wider rooms, since the tight corners make
> it a little tricky to move around.

I was confused by the small rooms.. nothing to
distinguish them from one another when the walls
are close...

I copied the layout of my house (3 levels) into the map
editor I made.. then I used the "tile" editor I made to
create my own tiles.. a staircase leading up, tv,
bookshelf, etc.. you can even go up/down stairs, and
end up on the appropriate level (no animation between levels,
it just jumps to where the stairs lead)

anyway.. it took about 10 minutes to make my house once
the editors were finished.. and it ends up being very clear
and easily playable..

as you are designing the map and tiles, you can go to the 3d
demo and view your work..

mess with it and make a few.. it's fun seeing it go together
so quickly.

Rich

[heuser...@freenet.de]

David Schmenk schrieb:

>
> I might put a disk image with the current source and tools I used for
> the demo out there if there was any interest.

Here's interest too!

bye
Marcus

[heuser...@freenet.de]

BLuRry schrieb:

>
> Also, look for "Way Out" by Sirius software. Sometimes it's attributed
> to the cracker "Aldo Reset" who took their name off of the title like a
> true punk. If you can't find it, I'll gladly send a disk image your
> way.

Yes, "Way Out" the Paul Edelstein classic from 1982.
He did the original on the Atari and all the conversions (C64/Apple)
himself because he didn't want to part with the source.
Because of this I used to call him "Gemstone Warrior" ;-)
("Edelstein" = German word for "gemstone")

For years there was nothing similar on the market.
AFAIK Castle Wolfenstein was the next game using a raycaster.

bye
Marcus

[Michael J. Mahon]

You can shift by 4 with a lookup table and a load...

[Michael J. Mahon]

David Schmenk wrote:

> BTW, I have made a decision to change the tools I use to build with.
> Originally I was going to keep it all self-hosted on an Apple II using
> Merlin. This demo pretty much maxed out my patience with that approach.
> I actually had to delete some comments in order to build the object
> file without running out of memory. I would have to resort to disk
> swapping the source to build anything bigger. Not gonna happen. So I'm
> switching to the cc65 assembler/linker tools and build under OS X. I
> might put a disk image with the current source and tools I used for the
> demo out there if there was any interest.

It is easy to subdivide (and modularize) any Merlin program by
using PUT statements to include other source files.

I'd certainly be interested in your current source and tools.

[David Schmenk]

... and an index register. Lookup tables are definitely an important
part of 6502 programming. And that doesn't even answer the question of
shifting which nibble where. It's what makes the 6502 such an
interesting architecture to work with. Sort of a pathological case of
the RISC philosophy. Name that Tune for CPUs - I can write that
algorithm in 6 bytes and one register, Pat! I read somewhere that the
designers of the ARM chip were somehow associated with the designers of
the 6502. Having written a 6502 emulator in 68000 assembly
(http://palmapple.sf.net) I would like to try using the ARM someday.
There seems to be an almost one-to-one match of the opcodes. Even the
mnemonics are similar. OK, where was I going with that? It's early.
I'm rambling. I need coffee.

Dave...

[David Schmenk]

My reference to disk swapping the source was from trying the PUT
statement. It certainly works, but still excruciating. I'll put
together a disk when I get back home on Sunday.

Dave...

[David Schmenk]

BLuRry wrote:
> aiia...@gmail.com wrote:
>> aiiad...@gmail.com wrote:
>>> You might want to contact Blurry, at
>>> http://brendan.robert.googlepages.com/
>> His 3d demo (in lores) was in the "other"
>> section in the small frame on the page,
>> but the "other" page is broken now..
>>
>> Rich
>
> Yeah, some turd started trying to play "guess the password" with
> various remote access ports in my home network, so I shut off all port
> forwards until they get a life and find something better to do. This
> unfortunately included taking the apache server that hosted part of my
> homepage offline as well.
>

Sorry to hear that. I've been there as well, which is why I was
reluctant to put a link to my server.

> Wow, is all I can say. I started implementing a raycaster using lo-res
> as well, as Rich said -- and had gotten stalled because of logical
> clipping errors (which junked up display from time to time). However,
> I can say you completely blew my experiment out of the water. Great
> stuff!!! I was hoping for my own endeavor to add tile support, but was
> assuming it was completely impossible to do while maintaining a decent
> framerate. And not only did you manage a decent framerate but also
> JOYSTICK support! :-O Crazy. Can you make //e keyboard support
> configurable so that joystick support can be disabled to save some
> cycles?
>
> My only recommendation is to go with little/no sound to save cycles and
> use an interrupt-driven mockingboard routine for music/sfx later on.
> I've written one and now that a2gameserver is stable can test it with
> my //e for whenever you feel you want a copy. Maybe you can pause
> playback for incidental SFX like "THWACK!" if the person smacks
> face-first into a wall (and Mahon's DAC522 would be a great candidate
> for crystal-clear SFX). Otherwise, I think playability would be more
> easily maintained if you had wider rooms, since the tight corners make
> it a little tricky to move around. But who am I to complain? This
> thing ROX!
>

Thanks. I decided to use my joystick reading while making sound routine
because it seemed that it got you both without compromising too much.
However the sound output is nothing to write home about. Nothing like
Michael Mahon's excellent DAC implementation. More like blips at
slightly different tones, but blips nevertheless. I think it would be
great to add some DAC522 sound effects - totally blow people away. As I
have no knowledge of Mockingboard programming (or a Mockingboard), I'll
take you up on the offer. I will add some keyboard support, but don't
expect too much. And as for the map, I intentionally kept it small
because I typed it in by hand. I laid it out on graph paper and
transcribed it into HEX statements. Shortly after that I wrote a crusty
map editor. The map is only 32x32 in the demo but the engine is capable
of any power-of-two up to 128 x (however much memory you have). I think
a good size for a map is around 64x64. I believe Rich is going to town
on creating map levels!

> Also, look for "Way Out" by Sirius software. Sometimes it's attributed
> to the cracker "Aldo Reset" who took their name off of the title like a
> true punk. If you can't find it, I'll gladly send a disk image your
> way.
>
> Great stuff!
>

I have never come across "Way Out". I am not sure what the keys are,
but it sure looks cool. And hires too.

Dave...

[BLuRry]

> great to add some DAC522 sound effects - totally blow people away. As I
> have no knowledge of Mockingboard programming (or a Mockingboard), I'll
> take you up on the offer. I will add some keyboard support, but don't
> expect too much.

:-) good stuff. I'm not expecting miracles, especially not for free.

As for the mockingboard bit, it is interrupt-driven so it only fires
off when it absolutely needs to. I'm trying to configure the routine
such that the frequency at which it is triggered is configurable. The
format of the sound is somewhat mod-like (except no digital samples,
just music data). I got kinda stalled because of the game server
(which I needed to bootstrap the test programs to my //e more quickly)
and now because I have a totally other side project going on -- for
which I'll post separately so I don't hijack your thread. ;-)

I'll let you know when I get the mockingboard routine working, though
it might be a while.

-B

[aiia...@gmail.com]

David Schmenk wrote:
> I have never come across "Way Out". I am not sure what the keys are,
> but it sure looks cool. And hires too.
>

-e-
sdf

E is north, s west, F east,
D is forward..

Rich

[aiia...@gmail.com]

David Schmenk wrote:
>I believe Rich is going to town on creating map levels!

YEAH... ITS easy and fast with the editor...

I need to find a wolf 3d site with printouts of the levels,
as well as 'textures' to copy...

Rich

[heuser...@freenet.de]

aiia...@gmail.com schrieb:

> David Schmenk wrote:
> >I believe Rich is going to town on creating map levels!
>
> YEAH... ITS easy and fast with the editor...
>
> I need to find a wolf 3d site with printouts of the levels,

Here are GIFs:
http://www.belowe.com/wolf3d.htm

> as well as 'textures' to copy...

http://www.areyep.com/RIPandMCS-TextureLibrary.html
Not the originals, though.
You would have to extract them from the demo/full game.

bye
Marcus

[aiia...@gmail.com]

aiia...@gmail.com wrote:
> aiia...@gmail.com wrote:
> > David Schmenk wrote:
> > > Here for your enjoyment is a technology preview/demonstration of a
> > > raycasting and rendering algorithm
> >
> > here is a texture/ "tile" editor, as well as MAP editor...

the texture editor display code is now in assembly.. much nicer to
work with.. next to change the map display code to assembly..

Rich

[aiia...@gmail.com]

the display code for the texture editor and map editor
are now in assembly, so it is speedy on a
real apple II!

email for a copy..

Rich

[aiia...@gmail.com]

aiia...@gmail.com wrote:
> anyway.. it took about 10 minutes to make my house once
> the editors were finished.. and it ends up being very clear
> and easily playable..

I figured out another possible trick...

make texture X a door in the "open door" code,
but make the graphic a wall..

hidden passage!

Rich

[heuser...@freenet.de]

aiia...@gmail.com schrieb:

>
> I figured out another possible trick...
>
> make texture X a door in the "open door" code,
> but make the graphic a wall..
>
> hidden passage!

That would be too well hidden (as in W3D) - better but a little
something in it that differentiates it from a normal, solid wall.

As a (bad) example: In the 2D Ultima games the secret door
tile had an extra pixel in the middle of the tile between the
bricks.

bye
Marcus

[Michael J. Mahon]

IIRC, the Mockingboard disk contains an interrupt-driven player. And
the Music Construction Set (not the IIgs version) also generates music
that is played by an interrupt-driven player.

ISTR that the Mockinboard disk version (I think) was even "packaged" to
be used by other programs.

The Mockingboard makes this pretty easy, since it contains *two* 6522
VIA chips, each of which has two timers with interrupt capability!

[Michael J. Mahon]

Ah--I've become totally spoiled by a CFFA and an 8MHz Zip Chip. ;-)
(Though I've lately been using Apple II Oasis on a PC and Merlin 8.
It's easy to get nice-looking listings after capturing to a file.)

[aiia...@gmail.com]

David Schmenk wrote:
> Here for your enjoyment is a technology preview/demonstration of a

> raycasting and rendering algorithm I have developed as part of my Apple
> II 30th birthday-retro-game-just-because-I-can thing.

would be cool if you could add a couple of lines to the beginning of
your
code, and make textures/maps relocatable... IE load them wherever
you want (not in GR screen, your demo code, etc)...

then I could choose somewhere besides $2000 for maps, and still
use the HGR screen for the editor.. no disk accesses to reload
the map after HGR access would speed it up.

Rich

[aiia...@gmail.com]

David Schmenk wrote:
> Here for your enjoyment is a technology preview/demonstration of a
> raycasting and rendering

ok, I'll just keep track of my progress here:

http://rich12345.tripod.com/loresthreed/index.html

[Jerry]

aiia...@gmail.com wrote:

>
> Jerry wrote:
>> for that, why not just compute PIX= C * 17 ?
>
> there are 3 routines in the assembly,
>
> 1)AND with #$0F (to strip high nibble, leave low nibble)
> 2)AND with #$F0 (to strip low nibble, leave high nibble)
> 3)match high nibble to low nibble (lda 8000, ROLX4, ORA 8000)
>
> could all be done with applesoft.. but I'm going to be converting
> the map display and texture display code to assembly today,
> so I figured I might as well start thinking 6502

Yes, that makes sense.

--
-- Jerry

[Linards Ticmanis]

Michael J. Mahon wrote:

> The Mockingboard makes this pretty easy, since it contains *two* 6522
> VIA chips, each of which has two timers with interrupt capability!

And on a //e and above, if you program the Mockingboard with the right
number of cycles and then wait for VBL ($C019) before actually enabling
the counter, it makes a decent-enough VBL interrupt source too. That way
you can switch your double buffer in the blanking interval, preventing
tearing.

--
Linards

[David Schmenk]

Look at the demo loader program. There is a pointer to the map level at
$300, along with the map width in bytes at $302. The texture map base
pointer is at $306. Heck, from the source:
;
; GLOBAL PARAMETERS
;
MAPLVL = $0300 ;POINTER TO MAP LEVEL
MAPSTRD = $0302 ;MAP WIDTH IN BYTES
RETCODE = $0303 ;RETURN CODE 0=EXIT FF=ESC
TEXBASE = $0306 ;BASE ADDRESS FOR TEXTURES
PLAYERX = $0308 ;X COORD OF PLAYER 8.8 FIX PT
PLAYERY = $030A ;Y COORD OF PLAYER 8.8 FIX PT
PLAYERA = $030C ;VIEW ANGLE OF PLAYER 0..255

You can set theses values to locate the maps and player position
wherever you like. The code is currently assembled for $6000 so that
needs to stay.

Dave..

[David Schmenk]

Yes, the CFFA is the only way I can use my IIgs. A great product. I
use one on my III as well.

I was able to quickly convert my source to cc65. There are differences
in the psuedo-ops, and some slight other differences. I use the Virtual
][ emulator which has the ability to mount a directory as a ProDOS
partition. Its easy to assemble, fire up the emulator, and run. My
Powerbook is a little more portable than my II as well :-) I think I
can keep the source incompatibilities to a minimum so that it can be
built under Merlin with some minor edits. Maybe a sed script can
convert the differences between the two.

Dave...

[Michael J. Mahon]

You can also program one timer to create an interrupt repeatedly,
with a period of one vertical frame. You then have to poll VBL
(or use "vapor lock" technique) to get the phase synchronized.

This will stay in sync, once established, because the Mockingboard is
locked by the Apple II clock.

That way, once sync is established, you never have to wait for VBL
again.

[Michael J. Mahon]

David Schmenk wrote:

> I was able to quickly convert my source to cc65. There are differences
> in the psuedo-ops, and some slight other differences. I use the Virtual
> ][ emulator which has the ability to mount a directory as a ProDOS
> partition. Its easy to assemble, fire up the emulator, and run. My
> Powerbook is a little more portable than my II as well :-) I think I
> can keep the source incompatibilities to a minimum so that it can be
> built under Merlin with some minor edits. Maybe a sed script can
> convert the differences between the two.

Cool--the best of both worlds!

[mdj]

David Schmenk wrote:

> I was able to quickly convert my source to cc65. There are differences
> in the psuedo-ops, and some slight other differences. I use the Virtual
> ][ emulator which has the ability to mount a directory as a ProDOS
> partition. Its easy to assemble, fire up the emulator, and run. My
> Powerbook is a little more portable than my II as well :-) I think I
> can keep the source incompatibilities to a minimum so that it can be
> built under Merlin with some minor edits. Maybe a sed script can
> convert the differences between the two.

If you come up with said sed (hey! almost!) script I'd be interested in
that. Of course, we'd need two scripts for going each way...

I had considered a while back writing a merlin compatible cross
assembler in some high level language, but generally speaking I've
found that my IIe (Transwarp, SCSI disks) assembles "fast enough", and
emulators running with restrictions turned off are probably going to be
as fast or faster than a compatible native assembler (assuming the use
of an interpreter)

Matt

[Jeff Blakeney]

To: heuser.marcus

On Fri, 19 Jan 2007 14:06:23 -0800, "heuser.marcus"
<heuser...@freenet.de> wrote:

>Here are GIFs:
>http://www.belowe.com/wolf3d.htm

That's cool. I wonder how well those maps match up with Wolf3D on the
IIgs as I believe most of its levels came from the Mac version and
from Mac add on levels.

>> as well as 'textures' to copy...
>
>http://www.areyep.com/RIPandMCS-TextureLibrary.html
>Not the originals, though.
>You would have to extract them from the demo/full game.

Now some of those tiles would probably be quite handy to use with
something written with GTE.

Jeff Blakeney
- to send me e-mail, CUT the obvious from my e-mail address
--- Synchronet 3.13a-Win32 NewsLink 1.83
A2Central.com - Your total source for Apple II computing.

[aiia...@gmail.com]

Jeff Blakeney wrote:
>
> Now some of those tiles would probably be quite handy to use with
> something written with GTE.
>
> Jeff Blakeney

Side scrolling platform game, Wolfen Bros. IID ?

Rich

[heuser...@freenet.de]

aiia...@gmail.com schrieb:

> Jeff Blakeney wrote:
> >
> > Now some of those tiles would probably be quite handy to use
> > with something written with GTE.
>

> Side scrolling platform game, Wolfen Bros. IID ?

Why not? It started as a 2D Action-Adventure.

The Japanese "Metal Slug" series from SNK are a 2D non-stop
action shooters with team play, fights againt storm troopers and
swastikas to boot.

And there is also a 2D-Half-Life-variant...

bye
Marcus

[aiia...@gmail.com]

heuser...@freenet.de wrote:
> The Japanese "Metal Slug" series from SNK are a 2D non-stop
> action shooters with team play, fights againt storm troopers and
> swastikas to boot.

Metal slug is a fun game...

>
> And there is also a 2D-Half-Life-variant...

cool...

Rich

[Michael Kent]

In comp.sys.apple2 David Schmenk <dsch...@yuch.gmail.com> wrote:

> Here for your enjoyment is a technology preview/demonstration of a
> raycasting and rendering algorithm I have developed as part of my Apple

> II 30th birthday-retro-game-just-because-I-can thing. Reminiscent of
> Wolfenstein 3D, it runs on a standard 1 MHz 48K Apple II+ (or II w/
> Applesoft in RAM/ROM) or greater. Only a joystick is required. It is
> possible to run it on an emulator, but I highly recommend using real
> hardware with a color monitor. Accelerators make it run too fast, so
> disable them if you want the controls to be sane. I present it as a
> 140K DOS 3.3 disk image compressed with gzip. Download with this URL:

This sounds awfully cool! But do you really need to distribute individual
files as a disk archive? Requiring a 5.25 inch drive just to unarchive
files not inherently tied to a disk format leaves those of us without
5.25 inch drives out in the cold.

Mike

[aiia...@gmail.com]

On Jan 23, 7:03 pm, Michael Kent <mich...@syndicomm.remove.this.com>
wrote:

> Requiring a 5.25 inch drive just to unarchive
> files not inherently tied to a disk format leaves those of us without
> 5.25 inch drives out in the cold.

come on inside and warm up... google CiderPress

Rich

[David Schmenk]

Not sure what the options really are here - I am not distributing just a
single file. I could have gone with a ShrinkIt archive, but I find them
a hassle on a non-IIgs. DOS 3.3 is the target, so a DSK format seems
the most obvious. Also easy to use with emulators. You can get a2tools
to easily extract files from a DSK image and do with them as you like.

Dave...

[sicklittlemonkey]

On Jan 24, 10:13 am, aiiad...@gmail.com wrote:
> come on inside and warm up... google CiderPress

CiderPress is great for Windows.

There's also the Java-based AppleCommander:
http://www.wright.edu/~john.matthews/ac.html

And other options, no doubt.

Cheers,
Nick.

[Michael Kent]

aiia...@gmail.com wrote:

OK. It appears to be some sort of Windows program. Now what?

Mike

[Michael Kent]

David Schmenk <dsch...@gach.gmail.com> wrote:

> Not sure what the options really are here - I am not distributing just a
> single file.

Since the files are only 11K, you could've just posted them individually
wrapped in Binary II headers to preserve the filetypes. That's not the
usual way, but it would work.

> I could have gone with a ShrinkIt archive

That's been the standard for about 20 years now.

> DOS 3.3 is the target, so a DSK format seems the most obvious.

Oh. It requires DOS 3.3. Never mind then. I thought that, being Apple-
soft and 6502 assembly, the files would work under ProDOS (i.e. independent
of a 5.25" disk).

> You can get a2tools

An Amiga toolset. So far I've been recommended a Windows application,
a JAVA application, and an Amiga toolset. Considering I'd like to run a
lo-res graphics -- a format found only on the Apple II -- program written
in Applesoft -- a language found only on the Apple II -- and posted on
comp.sys.apple2 -- an Apple II newsgroup -- how about a format actually
usable on an Apple II?

Mike

[David Schmenk]

Um, a2tools run on just about everything. More or less standard C code.
The DSK image pretty much fits the bill. Not sure why you can't
figure it out.

Dave...

[Tim Haynes]

Considering that the people are giving a newbie (you) some free
information and software out the goodness of their hearts, you might
consider being a bit more cordial.

Thanks
Tim

[aiia...@gmail.com]

On Jan 24, 10:52 pm, Michael Kent <mich...@syndicomm.remove.this.com>
wrote:

> David Schmenk <dschm...@gach.gmail.com> wrote:
> > Not sure what the options really are here - I am not distributing just a

> > single file.Since the files are only 11K, you could've just posted them individually

> wrapped in Binary II headers to preserve the filetypes. That's not the
> usual way, but it would work.

ewww... I haven't seen anyone do that on this newsgroup in years
(10??)

> It requires DOS 3.3. Never mind then. I thought that, being Apple-
> soft and 6502 assembly, the files would work under ProDOS (i.e. independent
> of a 5.25" disk).

The 6502 code runs without a problem under ProDos

> > You can get a2tools
>An Amiga toolset. So far I've been recommended a Windows application,
> a JAVA application, and an Amiga toolset.

you have to download it somehow... Are you downloading with an Apple
II?

A2tools is NOT an "amiga toolset"... it is a program available for
many platforms,
that allows you to "import" files into a disk image.

> Considering I'd like to run a-- program written

> in Applesoft -- a language found only on the Apple II --

The program is 6502 assembly language, compiled to 6502 machine
language. The only AppleSoft is a startup/ initialization program.

>and posted on
> comp.sys.apple2 -- an Apple II newsgroup -- how about a format actually
> usable on an Apple II?

It is very usable on the Apple II.. You might like to read this
newsgroup
for a bit, and get to know what's going on in this *hobby* group. We
have
PC, MAC tools available that allow us to download files (SHK, DSK, NIB,
etc), manipulate them, and then send them to the Apple II via serial
card,
ethernet, gameport, etc..

Rich

[magnusfalkirk]

On Jan 17, 2:10 am, David Schmenk <dschm...@YUCH.gmail.com> wrote:
> Here for your enjoyment is a technology preview/demonstration of a
> raycasting and rendering algorithm I have developed as part of my Apple
> II 30th birthday-retro-game-just-because-I-can thing. Reminiscent of
> Wolfenstein 3D, it runs on a standard 1 MHz 48K Apple II+ (or II w/
> Applesoft in RAM/ROM) or greater. Only a joystick is required. It is
> possible to run it on an emulator, but I highly recommend using real
> hardware with a color monitor. Accelerators make it run too fast, so
> disable them if you want the controls to be sane. I present it as a
> 140K DOS 3.3 disk image compressed with gzip. Download with this URL:
>

> http://schmenk.is-a-geek.com/tarfiles/raydemo.dsk.gz
>
> I hope it doesn't end up being a bad idea placing a direct link, but its
> only 11K in size.
>
> Just a little background - I have a pile of algorithms I've been
> creating in my notebook for some time. Some people like Soduku for
> their diversion, I like 6502 assembly language. The 30th anniversary of
> the Apple II seemed like a good time to put some of them together. Its
> always fun to make old (obsolete) hardware do things people don't
> expect. In this case, a full screen 3D walkthrough. However, don't
> think I've made an Apple II perform like NVIDIA's latest GPU. In order
> to get interactive framerates and decent colors, the lo-res graphics
> mode is employed. I am not double buffering the rendering - you see it
> as it renders. Textures are only 16x16, and there are only 15 of them.
> It would have seemed pretty cool back in 1977 though.
>
> Download it, give it a try, let me know what you think. I hope to have
> an actual game to play with a geekly humorous story-line in a few months
> based on this technology.
>
> Dave...

Greetings,

I'm not sure if I'm doing something wrong or not. I've downloaded the
3d demo and it runs fine on the Apple II emulators I have on my Mac.
But when I transfer it to an actual disk and try to run it on my IIe
it crashes in machine language. Any ideas?

Thanks,
Dean

[David Schmenk]

Dean-
It should work just fine on your IIe. Perhaps the disk image got
corrupted during transfer. How did you copy from your Mac to IIe? Are
you able to CATALOG the disk after the transfer? Can you load the HELLO
file and list it? Is it good or gibberish? I use Virtual ]['s A2D2
program on my Mac (with a KeySpan USB -> serial adapter) and ADT 1.21 on
my II. Works great for me.
Dave...

[aiia...@gmail.com]

On Feb 1, 7:40 am, "magnusfalkirk" <dean.pha...@gmail.com> wrote:
> I'm not sure if I'm doing something wrong or not. I've downloaded the
> 3d demo and it runs fine on the Apple II emulators I have on my Mac.
> But when I transfer it to an actual disk and try to run it on my IIe
> it crashes in machine language. Any ideas?

You are probably referring to the Monitor.. it should show:
ABCD- A=00 X=00 Y=00 p = 00 s = 00

what address is it breaking on? (ABCD in above example)

Does your IIe run other software without a problem?
What cards does it have installed?

What method did you use to get the software on the
disk?

can you CATALOG this disk?

Rich

[magnusfalkirk]

David and Rich,

I was able to get the demo up and running finally, but I had to boot
the computer with another DOS disk first. If I try to boot the
raycasting demo disk itself it still dumps me into the monitor. Here
is what I've seen on the screen:

9E0E- A=A4 X=A8 Y=A4 P=B5 S=FB

That was the last time I tried booting it directly this morning. Last
night this is what I got:

0033- A=00 X=B8 Y=00 P=73 S=FF

and I got a different one this morning when I firs tried it:

9E0B- A=FD X=38 Y=1B P=30 S=FC

and to make it even more interesting one time it simply stopped with
"Apple II" as the only thing on the screen.

As to what cards are in the computer, there's the 80 column/64k card
in it's dedicated slot, slot 1 is the SSC, slot 4 has a mouse card and
slot 6 the Disk Drive controller. I was able to catalog the disk,
after I booted the II with another DOS disk. Then I loaded the demo
program, listed it (it was completely readable) and then ran it, It's
currently up on the IIe screen as I type this.

I use ADTPro, with a USB to Serial adapter, one similar to the Lindy
adapter, to transfer disk images from my Mac Mini to the IIe. Other
programs I've transferred run fine.

It took me a while to get it running but I really like it and hope
that you, David, do use this as a basis for a new game for the II.

Dean

[David Schmenk]

Dean-

If the image works fine on an emulator, try using a different 5 1/4
disk. These things are getting old and quite often get bad sectors. I
just got one yesterday doing the same crash as yours.

As for a game; patience, young one :-) I just got the sprites working
so its time for game content and creation tools.

Dave...

[magnusfalkirk]

On Feb 2, 9:36 am, David Schmenk <dschm...@GACH.gmail.com> wrote:

>> Dean-
>
> If the image works fine on an emulator, try using a different 5 1/4
> disk. These things are getting old and quite often get bad sectors. I
> just got one yesterday doing the same crash as yours.
>
> As for a game; patience, young one :-) I just got the sprites working
> so its time for game content and creation tools.
>
> Dave...

Dave,

I guess it was the disk. I tried copying the raydemo.dsk to two other
real disks. The first one failed just like before. The second one
booted all the way into the demo. Young one, huh? I bought my first
Apple II+ back in 1981 and I graduated high school the year before
Apple Computer got started. ;-)

Thanks for the advice.
Dean

[David Schmenk]

Dean - glad to hear it.

Sorry for the young one remark. I've got a birthday coming up and am
feeling particularly old and decrepit. Officially forty-something.
However, I got a boost to my psyche when I showed my current
work-in-progress to my fiancee's teenage boys and they said it was
'cool'. After which they went back to playing Oblivion on the XBOX 360.
Oh well.

Dave...

[BLuRry]

Augh! You people. I just turned 30 two days ago. :-D

[mdj]

On Feb 5, 2:16 pm, "BLuRry" <brendan.rob...@gmail.com> wrote:

> Augh! You people. I just turned 30 two days ago. :-D

Did it hurt ? ;-)