New Update.
- add player- add collisions- add "monsters"- some optimizations.
But now i need to optimize the rendering of camera with a best solution of that.
Clear the rendering area is not a best solution.
I need to draw and delete (fast) tiles left, right, up and down.
Any idea?Tnx
sorry for my poor english :(
10 clear:mode 0: ON BREAK GOSUB 8000
11 OUT &BC00,0:OUT &BD00,127
12 OUT &BC00,4:OUT &BD00,18
13 OUT &BC00,5:OUT &BD00,15
14 OUT &BC00,6:OUT &BD00,15
15 OUT &BC00,7:OUT &BD00,17
18 border 0: ink 0,0:call &BD19
20 mx%=20:my%=11:cx%=3:cy%=3:DIM map%(mx%,my%):DIM camera%(cx%,cy%):movx%=1:movy%=1
30 XOROn$=CHR$(23)+CHR$(1):XOROff$=CHR$(23)+CHR$(0)
50 gosub 3000:gosub 2000
500 while 1 'Main Loop
505 call &BD19 'frame
550 IF NOT(INKEY(1)) AND (movx%<18) AND NOT(map%(1+movx%+1,1+movy%)=1) THEN gosub 7000:movx%=movx%+1:gosub 2000
560 IF NOT(INKEY() AND (movx%>0) AND NOT(map%(1+movx%-1,1+movy%)=1) THEN gosub 7000:movx%=movx%-1:gosub 2000
570 IF NOT(INKEY(0)) AND (movy%>0) AND NOT(map%(1+movx%,1+movy%-1)=1) THEN gosub 7000:movy%=movy%-1:gosub 2000
580 IF NOT(INKEY(2)) AND (movy%<9) AND NOT(map%(1+movx%,1+movy%+1)=1) then gosub 7000:movy%=movy%+1:gosub 2000
1500 wend
2000 'Camera
2005 sound 1,50,1,15:locate 1+movx%,1+movy%:PEN 3:PRINT CHR$(249);:
2010 IF map%(1+movx%,1+movy%)=2 THEN SOUND 1,800,10,15,2,10,1:goto 10
2015 x2%=movx%:y2%=movy%: locate 1,14:pen 3:Print " Castle Dungeon CPC ":locate 1,15:Print " www.retroacademy.it ":
2040 FOR y%=1 TO cy%
2050 FOR x%=1 TO cx%
2080 LOCATE (x%+movx%)-1,(y%+movy%)-1
2085 IF map%(x2%,y2%)=1 THEN PEN 2: print CHR$(127);:
2090 'IF map%(x2%,y2%)=0 then print " ";:
2092 IF map%(x2%,y2%)=2 then PEN 3: print CHR$(253);:
2110 x2%=x2%+1
2120 NEXT x%
2130 y2%=y2%+1:x2%=movx%
2150 NEXT y%
2180 return
3000 'map
3010 restore 5000
3050 for y%=1 to my%
3100 for x%=1 to mx%
3150 READ a%:map%(x%,y%)=a%:LOCATE x%,y%
3200 'if map%(x%,y%)=1 then PRINT CHR$(15);CHR$(;CHR$(207);:
3250 NEXT x%
3300 NEXT y%
3350 RETURN
4000 'Tiles
4050 PRINT CHR$(15);CHR$(;CHR$(207);:RETURN
5000 'Map Data
5010 DATA 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1
5100 DATA 1,0,0,0,0,0,1,0,0,0,0,0,0,2,0,0,0,1,0,1
5200 DATA 1,1,1,1,1,0,1,0,2,0,0,1,0,0,0,0,0,1,0,1
5300 DATA 1,0,1,0,0,0,1,0,0,0,0,1,1,1,1,2,0,1,0,1
5400 DATA 1,0,1,0,0,0,0,0,0,0,0,1,0,0,0,0,0,0,0,1
5500 DATA 1,0,1,0,1,1,1,1,1,0,0,1,0,1,1,1,1,0,0,1
5600 DATA 1,0,2,0,0,0,0,0,1,0,0,0,0,1,0,0,0,0,0,1
5700 DATA 1,0,1,1,0,1,1,1,1,1,1,1,1,1,1,1,0,0,0,1
5800 DATA 1,0,1,0,0,0,0,0,0,0,1,0,0,0,0,0,0,1,1,1
5900 DATA 1,0,0,0,0,0,0,2,0,0,0,0,1,0,0,1,0,0,0,1
6000 DATA 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1
6999 'Clear camera only
7000 FOR y%=1 TO cy%
7010 FOR x%=1 TO cx%
7020 LOCATE (x%+movx%)-1,(y%+movy%)-1
7030 print " ";:
7040 NEXT x%
7050 x2%=movx%
7060 NEXT y%
7070 return
8000 CLEAR:CALL &BC02:PEN 1:MODE 2:print "Hi, Visit www.retroacademy.it ":print" "
8010 OUT &BC00,0: OUT &BD00,&3F
8020 OUT &BC00,1: OUT &BD00,&28
8030 OUT &BC00,2: OUT &BD00,&2E
8040 OUT &BC00,3: OUT &BD00,&8E
8050 OUT &BC00,4: OUT &BD00,&26
8060 OUT &BC00,5: OUT &BD00,&00
8070 OUT &BC00,6: OUT &BD00,&19
8080 OUT &BC00,7: OUT &BD00,&1E
8090 OUT &BC00,8: OUT &BD00,&00
8100 OUT &BC00,9: OUT &BD00,&07
8110 OUT &BC00,10: OUT &BD00,&00
8120 OUT &BC00,11: OUT &BD00,&00
8130 OUT &BC00,12: OUT &BD00,&30
8140 OUT &BC00,13: OUT &BD00,&00
8150 OUT &BC00,14: OUT &BD00,&00
8160 OUT &BC00,15: OUT &BD00,&00
Line 520 is exclusive to BASIC 1.1, it could be replaced with 520 CALL &BD19 which is what that BASIC 1.1 is, though it's a call to Firmware, the alternative BASIC approach is a delayed FOR loop, though I don't have any accurate timings of this in BASIC, perhaps something could be rigged up. Here's one weird approach involving a TIME delay:
10 MODE 1:p=0
20 WHILE 1
30 LOCATE 1,1:p=p+1:PRINT p;
40 t2=TIME/300
50 WHILE t2>t:t=TIME/300.2:WEND
60 WEND
The delay in this case is line 50, line 40 sets up t2 as the initial counter, it's value is larger than t, so the WHILE loop is initiated, from there t=TIME/300.2 - the closer it gets to 300 the quicker the delayed loop exits. I'm unsure if it would help you in your game though, I tried setting it as t=TIME/300.01 and watch my number count very quickly, t=TIME/300.05 or 300.04 produce a more delayed response.
This might be of some use, I wrote it so now it uses TAG:TAGOFF along with the use of a TIME delay, with it you could compare how quick you want the delay along with your FRAME example, simply REM lines 140 & 150 when you're using FRAME and REM out FRAME when using 140 & 150, as you will see I now have a number with 5 decimal places which is probably just fractionally longer than the FRAME counterpart.
100 MODE 1:p=0:x=0:y=398
110 PRINT CHR$(23);CHR$(1);
120 WHILE 1
130 MOVE x,y:p=p+1:TAG:PRINT p;:TAGOFF
140 t2=TIME/300
150 WHILE t2>t:t=TIME/300.00005:WEND
160 ox=x:x=x+2:IF x>576 THEN x=0
170 oy=y:y=y-2:IF y<16 THEN y=398
180 MOVE ox,oy:TAG:PRINT p;:TAGOFF
190 WEND
Hi, if you want, here ny Code :)
10 clear:mode 0: border 0: ink 0,0
11 OUT &BC00,0:OUT &BD00,127
12 OUT &BC00,4:OUT &BD00,18
13 OUT &BC00,5:OUT &BD00,15
14 OUT &BC00,6:OUT &BD00,15
15 OUT &BC00,7:OUT &BD00,17
20 mx%=20:my%=11:cx%=4:cy%=3:DIM map%(mx%,my%):DIM camera%(cx%,cy%):movx%=1:movy%=1
30 XOROn$=CHR$(23)+CHR$(1):XOROff$=CHR$(23)+CHR$(0)
50 gosub 3000
60 FOR x%=1 TO cx%
70 FOR y%=1 TO cy%
80 camera%(x%,y%)=0
90 NEXT y%
100 NEXT x%
150 gosub 2020
500 while 1 'Main Loop
505 call &BD19 'frame
550 IF NOT(INKEY(1)) AND (movx%<17) THEN movx%=movx%+1:gosub 2030
560 IF NOT(INKEY() AND (movx%>1) THEN movx%=movx%-1:gosub 2030
570 IF NOT(INKEY(0)) AND (movy%>1) THEN movy%=movy%-1:gosub 2030
580 IF NOT(INKEY(2)) AND (movy%<9) then movy%=movy%+1:gosub 2030
1500 wend
2020 'Camera
2030 clg : x2%=movx%:y2%=movy%:locate 1,13:Print "Castel Dungeon CPC":locate 1,14:Print "www.retroacademy.it":
2040 FOR y%=1 TO cy%
2050 FOR x%=1 TO cx%
2070 camera%(x%,y%)=map%(x2%,y2%)
2080 LOCATE x%+movx%-1,y%+movy%
2085 IF map%(x2%,y2%)=1 THEN PEN 2: print CHR$(127);:
2090 IF map%(x2%,y2%)=0 then PEN 2: print CHR$(143);:
2110 x2%=x2%+1
2120 NEXT x%
2130 y2%=y2%+1
2140 x2%=movx%
2150 NEXT y%
2160 return
3000 'map
3010 restore 5000
3050 for y%=1 to my%
3100 for x%=1 to mx%
3150 READ a%:map%(x%,y%)=a%:LOCATE x%,y%
3200 if map%(x%,y%)=1 then PRINT CHR$(15);CHR$(;CHR$(207);:
3250 NEXT x%
3300 NEXT y%
3350 RETURN
4000 'Tiles
4050 PRINT CHR$(15);CHR$(;CHR$(207);:RETURN
5000 'Map Data
5010 DATA 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1
5100 DATA 1,0,0,0,0,0,1,0,0,0,0,0,0,0,0,0,0,1,0,1
5200 DATA 1,1,1,1,1,0,1,0,0,0,0,1,0,0,0,0,0,1,0,1
5300 DATA 1,0,1,0,0,0,1,0,0,0,0,1,1,1,1,0,0,1,0,1
5400 DATA 1,0,1,0,0,0,0,0,0,0,0,1,0,0,0,0,0,0,0,1
5500 DATA 1,0,1,0,1,1,1,1,1,0,0,1,0,1,1,1,1,0,0,1
5600 DATA 1,0,0,0,0,0,0,0,1,0,0,0,0,1,0,0,0,0,0,1
5700 DATA 1,1,1,0,0,1,1,1,1,1,1,1,1,1,1,1,0,0,0,1
5800 DATA 1,0,1,0,0,0,0,0,0,0,0,0,1,0,0,0,0,1,1,1
5900 DATA 1,0,0,0,0,0,0,0,0,0,0,0,1,0,0,1,0,0,0,16000 DATA 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1
Engine Update :)
https://www.youtube.com/watch?v=txjXJ7fWi1Qhttp:// (https://www.youtube.com/watch?v=txjXJ7fWi1Qhttp://)
New Update.
- add player- add collisions- add "monsters"- some optimizations.
But now i need to optimize the rendering of camera with a best solution of that.
Clear the rendering area is not a best solution.
I need to draw and delete (fast) tiles left, right, up and down.
Any idea?Tnx
sorry for my poor english :(
10 clear:mode 0: ON BREAK GOSUB 8000
11 OUT &BC00,0:OUT &BD00,127
12 OUT &BC00,4:OUT &BD00,18
13 OUT &BC00,5:OUT &BD00,15
14 OUT &BC00,6:OUT &BD00,15
15 OUT &BC00,7:OUT &BD00,17
18 border 0: ink 0,0:call &BD19
20 mx%=20:my%=11:cx%=3:cy%=3:DIM map%(mx%,my%):DIM camera%(cx%,cy%):movx%=1:movy%=1
30 XOROn$=CHR$(23)+CHR$(1):XOROff$=CHR$(23)+CHR$(0)
50 gosub 3000:gosub 2000
500 while 1 'Main Loop
505 call &BD19 'frame
550 IF NOT(INKEY(1)) AND (movx%<18) AND NOT(map%(1+movx%+1,1+movy%)=1) THEN gosub 7000:movx%=movx%+1:gosub 2000
560 IF NOT(INKEY(8)) AND (movx%>0) AND NOT(map%(1+movx%-1,1+movy%)=1) THEN gosub 7000:movx%=movx%-1:gosub 2000
570 IF NOT(INKEY(0)) AND (movy%>0) AND NOT(map%(1+movx%,1+movy%-1)=1) THEN gosub 7000:movy%=movy%-1:gosub 2000
580 IF NOT(INKEY(2)) AND (movy%<9) AND NOT(map%(1+movx%,1+movy%+1)=1) then gosub 7000:movy%=movy%+1:gosub 2000
1500 wend
2000 'Camera
2005 sound 1,50,1,15:locate 1+movx%,1+movy%:PEN 3:PRINT CHR$(249);:
2010 IF map%(1+movx%,1+movy%)=2 THEN SOUND 1,800,10,15,2,10,1:goto 10
2015 x2%=movx%:y2%=movy%: locate 1,14:pen 3:Print " Castle Dungeon CPC ":locate 1,15:Print " www.retroacademy.it ":
2040 FOR y%=1 TO cy%
2050 FOR x%=1 TO cx%
2080 LOCATE (x%+movx%)-1,(y%+movy%)-1
2085 IF map%(x2%,y2%)=1 THEN PEN 2: print CHR$(127);:
2090 'IF map%(x2%,y2%)=0 then print " ";:
2092 IF map%(x2%,y2%)=2 then PEN 3: print CHR$(253);:
2110 x2%=x2%+1
2120 NEXT x%
2130 y2%=y2%+1:x2%=movx%
2150 NEXT y%
2180 return
3000 'map
3010 restore 5000
3050 for y%=1 to my%
3100 for x%=1 to mx%
3150 READ a%:map%(x%,y%)=a%:LOCATE x%,y%
3200 'if map%(x%,y%)=1 then PRINT CHR$(15);CHR$(8);CHR$(207);:
3250 NEXT x%
3300 NEXT y%
3350 RETURN
4000 'Tiles
4050 PRINT CHR$(15);CHR$(8);CHR$(207);:RETURN
5000 'Map Data
5010 DATA 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1
5100 DATA 1,0,0,0,0,0,1,0,0,0,0,0,0,2,0,0,0,1,0,1
5200 DATA 1,1,1,1,1,0,1,0,2,0,0,1,0,0,0,0,0,1,0,1
5300 DATA 1,0,1,0,0,0,1,0,0,0,0,1,1,1,1,2,0,1,0,1
5400 DATA 1,0,1,0,0,0,0,0,0,0,0,1,0,0,0,0,0,0,0,1
5500 DATA 1,0,1,0,1,1,1,1,1,0,0,1,0,1,1,1,1,0,0,1
5600 DATA 1,0,2,0,0,0,0,0,1,0,0,0,0,1,0,0,0,0,0,1
5700 DATA 1,0,1,1,0,1,1,1,1,1,1,1,1,1,1,1,0,0,0,1
5800 DATA 1,0,1,0,0,0,0,0,0,0,1,0,0,0,0,0,0,1,1,1
5900 DATA 1,0,0,0,0,0,0,2,0,0,0,0,1,0,0,1,0,0,0,1
6000 DATA 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1
6999 'Clear camera only
7000 FOR y%=1 TO cy%
7010 FOR x%=1 TO cx%
7020 LOCATE (x%+movx%)-1,(y%+movy%)-1
7030 print " ";:
7040 NEXT x%
7050 x2%=movx%
7060 NEXT y%
7070 return
8000 CLEAR:CALL &BC02:PEN 1:MODE 2:print "Hi, Visit www.retroacademy.it ":print" "
8010 OUT &BC00,0: OUT &BD00,&3F
8020 OUT &BC00,1: OUT &BD00,&28
8030 OUT &BC00,2: OUT &BD00,&2E
8040 OUT &BC00,3: OUT &BD00,&8E
8050 OUT &BC00,4: OUT &BD00,&26
8060 OUT &BC00,5: OUT &BD00,&00
8070 OUT &BC00,6: OUT &BD00,&19
8080 OUT &BC00,7: OUT &BD00,&1E
8090 OUT &BC00,8: OUT &BD00,&00
8100 OUT &BC00,9: OUT &BD00,&07
8110 OUT &BC00,10: OUT &BD00,&00
8120 OUT &BC00,11: OUT &BD00,&00
8130 OUT &BC00,12: OUT &BD00,&30
8140 OUT &BC00,13: OUT &BD00,&00
8150 OUT &BC00,14: OUT &BD00,&00
8160 OUT &BC00,15: OUT &BD00,&00
This is a very interesting project.
You'll get a big speed boost by moving the printing of the text at the bottom out of the main loop.
Add this line:
100 locate 1,14:pen 3:Print " Castle Dungeon CPC ":locate 1,15:Print " www.retroacademy.it "
and change this line:
2015 x2%=movx%:y2%=movy%:rem locate 1,14:pen 3:Print " Castle Dungeon CPC ":locate 1,15:Print " www.retroacademy.it ":
Tnx ervin,
little forgetfulness :doh: I think without using ASM, we can still improve speed.
Quote from: ervin on 12:35, 03 October 18This is a very interesting project.
You'll get a big speed boost by moving the printing of the text at the bottom out of the main loop.
Add this line:
100 locate 1,14:pen 3:Print " Castle Dungeon CPC ":locate 1,15:Print " www.retroacademy.it "
and change this line:
2015 x2%=movx%:y2%=movy%:rem locate 1,14:pen 3:Print " Castle Dungeon CPC ":locate 1,15:Print " www.retroacademy.it ":
We certainly can.
8)
Instead of clearing the entire area around the player, only clear the cells to the left, right, top or bottom of the player, depending which way the player moves.
Then redraw every cell *around* the player (i.e. 8 cells).
Then draw the player.
Once that works, keep track of what each of the cells around the player contains.
If the cell doesn't need to be re-printed, don't print it!
(That is, if it will be printed with the same character again).
exactly that i will do :)it's the only way to speed-up.
Quote from: ervin on 13:21, 03 October 18We certainly can.
8)
Instead of clearing the entire area around the player, only clear the cells to the left, right, top or bottom of the player, depending which way the player moves.
Then redraw every cell *around* the player (i.e. 8 cells).
Then draw the player.
Once that works, keep track of what each of the cells around the player contains.
If the cell doesn't need to be re-printed, don't print it!
(That is, if it will be printed with the same character again).
I wonder if something could be done with inks?
That is, changing inks to display a cell or hide it, instead of re-drawing it?
I don't know if it's possible, because I'm not very good at ink usage, but if it's possible, it would make this program extremely fast.
Mission complete :D
https://www.youtube.com/watch?v=qo2i6v3dgac&feature=youtu.be (https://www.youtube.com/watch?v=qo2i6v3dgac&feature=youtu.be)
Quote from: ervin on 13:21, 03 October 18We certainly can.
8)
Instead of clearing the entire area around the player, only clear the cells to the left, right, top or bottom of the player, depending which way the player moves.
Then redraw every cell *around* the player (i.e. 8 cells).
Then draw the player.
Once that works, keep track of what each of the cells around the player contains.
If the cell doesn't need to be re-printed, don't print it!
(That is, if it will be printed with the same character again).
Quote from: Fabrizio Radica on 14:29, 03 October 18
Mission complete :D
https://www.youtube.com/watch?v=qo2i6v3dgac&feature=youtu.be (https://www.youtube.com/watch?v=qo2i6v3dgac&feature=youtu.be)
Fantastic!
You implemented that very quickly!
Now i would like to play music, but it's not so simple in basic. ::)
Quote from: ervin on 14:37, 03 October 18
Fantastic!
You implemented that very quickly!
Castle Dungeon demo compiled. Just find 5 coins without find the "beast" :)
Quote from: ervin on 14:37, 03 October 18
Fantastic!
You implemented that very quickly!
That's really cool.
:)
It's *very* fast now.
Which compiler did you use?
FAst BAsic COMpiler.
yes it's very fast, and... why don't try to add enemies now? ::)
Quote from: ervin on 00:58, 04 October 18That's really cool.
:)
It's *very* fast now.
Which compiler did you use?
Another Update :o
- Enemies using interrupts (<Every i,t> basic command)
- more speedup- bonus- sounds effects
...not compiled yet ;)
https://www.youtube.com/watch?v=-DjWNNjaqzY&feature=youtu.be (https://www.youtube.com/watch?v=-DjWNNjaqzY&feature=youtu.be)
Quote from: Fabrizio Radica on 06:47, 04 October 18FAst BAsic COMpiler.
yes it's very fast, and... why don't try to add enemies now? ::)
That runs really well.
I actually think it might be more playable uncompiled, as it's so fast compiled that it's very easy to run into an enemy.
:)
aaarrggghh!!!FAb BAsic COMpiler crash on <EVERY 1,t> command...so... now.. i need to change some routines for the monsters movements.
see you sooooon! (with the FINAL VERSION!!!)
Quote from: ervin on 14:36, 04 October 18That runs really well.
I actually think it might be more playable uncompiled, as it's so fast compiled that it's very easy to run into an enemy.
:)
OK... Final version of Castle Dungeon ;)
but... without interrupts... :(
Quote from: Fabrizio Radica on 18:25, 04 October 18aaarrggghh!!!FAb BAsic COMpiler crash on <EVERY 1,t> command...so... now.. i need to change some routines for the monsters movements.
see you sooooon! (with the FINAL VERSION!!!)
Really good.
That has turned out very nicely.
It looks great and runs very well too.
One thing I did notice though... it seems to be buffering keyboard commands.
When it's game over, there will sometimes be arrow symbols displayed on the line where the user can enter the castle number.
This game would be perfect for online multiplayer.
As a small optimisation consider the following. If you remove the map data and read that from a file directly poked into a reserved memory location then you can have unlimited maps as levels without additional memory usage.
It may alsp be faster to read dirextly from those memory locations as you can calculate directly around where ypur player is. And... If that is not fast enough or slower that model of storing the map data in memory would let you use a small machine code or rsx routine specifically for fast drawing without having to change too much other logic.
Then .. If using a fast draw routine you could change the colour slightly for the walls as they get farther away from your player character so there is a gradient of light to dark. Still keep it character based for charm
Another small thought... you test the 4 keys and each of them have their own calls to 2000 and 7000. If you only were to change mx and my but record the old version, omx and omy... after the 4 lots of key presses, check if either mx <> omx and my <> omy then call 2000 and 7000, you would then be able to move diaginally without a precedence given to either up down left or right... at the moment if trying to move diagonally, it instead moves left or right. If the intent is to not allow diagonal, then you can still test that only one of my or mx had changed the other way and therefore not move at all.
Not sure if this will work, but there is the clear loop and draw loop, both covering the same ground twice. If you were to do a virtual clear to a 3x3 array, then a virtual draw into that array, then a single redraw on the physical screen it might be faster too.
Quote from: zhulien on 10:02, 05 October 18
This game would be perfect for online multiplayer.
- you have centered my goal :)- i'm still coding a top score board in PHP
As a small optimisation consider the following. If you remove the map data and read that from a file directly poked into a reserved memory location then you can have unlimited maps as levels without additional memory usage.
- i've already make routines for fast loading maps from disk... and online (with M4)
It may alsp be faster to read dirextly from those memory locations as you can calculate directly around where ypur player is. And... If that is not fast enough or slower that model of storing the map data in memory would let you use a small machine code or rsx routine specifically for fast drawing without having to change too much other logic.
- for now, i don't want to use ASM or RSX because it's a challange with my self. but in near future why not...
Then .. If using a fast draw routine you could change the colour slightly for the walls as they get farther away from your player character so there is a gradient of light to dark. Still keep it character based for charm
can you explane how?
tnx mate, your help is much appreciated :)
you are currently drawing in mode 1. so there is only 4 colours. 1 for the player, 1 for monsters, 1 for walls and 1 for gold etc. With mode 1 perhaps it's the best combination of colours already. You could use a slightly less defined / more dithered wall representation for mode 1 further away walls?
if it was mode 0 (not sure you can make it as attractive, but if...) when you draw the walls around the viewport (your 3 x 3 array), you can first draw them into a new array which is like a double-buffer before actually displaying on the real screen. When you draw directly next to you, use a colour that is brightest, as you get to 2 characters away, then make the walls darker. Note: although your map is using a particular number for the walls, your small 3x3 buffer doesn't need to be constrained to those same representations. You could if in mode 0 have other pre-rendered effects in that buffer before actually transferring to the physical screen.
what's your thoughts on mode 0 vs mode 1? If Mode 0, you could make all gfx double size at little cost (without having to use the special screen mode). You could also do a 4 way scroll, or perhaps just horizontal scroll or just a vertical scroll (easier). Since almost everything is shrouded anyway, you don't have a lot to repaint if scrolling, it is just a recalculation based on your viewport origin for your painted viewport.
Mode 0 would also give you the ability to have multiple players in different colours? 4 at a time? 8 at a time?
If multiple players, if they are all shrouded for you too, then the same principle. They all have very little to draw. You could then not be constrained by map size to 1 screen.
Here is a cool Nintendo NES game dev video, to give you some tips on memory usage. The same principles could apply to your maps, but do it one step at a time I guess... for now it is easy to debug in it's simple representation.
https://www.youtube.com/watch?v=ZWQ0591PAxM (https://www.youtube.com/watch?v=ZWQ0591PAxM)
If you want help with the website, let me know. I am itching for someone to at least consider using the 8bitology.net API :P
Patch 1.1
Castle Dungeon patch 1.1
- Keys and Doors
- Fighting scenes
- some optimizations
Quote from: Fabrizio Radica on 19:02, 04 October 18OK... Final version of Castle Dungeon ;)
but... without interrupts... :(
Nice work - a little like my 2017 10-liner BASIC dungeon game except the monsters moved too slowly in mine, and you have implemented limited visibility.
Quote from: Sykobee (Briggsy) on 17:01, 05 October 18
Nice work - a little like my 2017 10-liner BASIC dungeon game except the monsters moved too slowly in mine, and you have implemented limited visibility.
where i find your game? :)
I just thought of the following worth a try perhaps. If you leave your player always in the same physical position of the screen eg... The middle. And move the entire map when the player moves. This might also be a speed improvement because... You only need to physically draw the bits of wall that change. You can also do this with 2 temporary arrays 3x3 or 5x5... You fill 1 with what needs be viewed. Checking the map with this against should-be-viewed array to create a should-be-updated array. Then physically update the screen. There may also be further array optimizations possible after that where array 2 is then also applied to array 1 so array 1 never needs a full read loop.
Other benefits would mean map sizes unbound by physical screen size but without any actual screen scrolling... You already have the illusion of it scrolling by fixing your players physical position.
I've in mind a shooter with scrolling.Obviously, in Basic it's unthinkable to scroll all tiles together without firmware calls. :doh: So i think to use this technics for unlimited scrolling :)
Thank's for your help :)
Quote from: zhulien on 03:06, 06 October 18I just thought of the following worth a try perhaps. If you leave your player always in the same physical position of the screen eg... The middle. And move the entire map when the player moves. This might also be a speed improvement because... You only need to physically draw the bits of wall that change. You can also do this with 2 temporary arrays 3x3 or 5x5... You fill 1 with what needs be viewed. Checking the map with this against should-be-viewed array to create a should-be-updated array. Then physically update the screen. There may also be further array optimizations possible after that where array 2 is then also applied to array 1 so array 1 never needs a full read loop.
Other benefits would mean map sizes unbound by physical screen size but without any actual screen scrolling... You already have the illusion of it scrolling by fixing your players physical position.
Interesting mechanics in this one. And with the speed updates it certainly is quite playable!
Very funny!!! :)
looking at the logic in here, a fairly small change could give you likely double the performance. Currently you have a map array and a camera array for which you are looping twice, the y% then the x%.
Instead of the map and camera being a 2 dimentional number array, if you make them single dimentional string arrays, then you can output transfer the map to the camera and output the camera faster. The only iterators you then need in BASIC are the y% iterators. The x% iterator you replace directly with a camera(y%) = mid$(blah, 3, 3) and for displaying just output the entire camera string at the right screen location. Since BASIC's print function is now handling the x% iterator it will be much much faster than treating everything a character at a time.
Another speedup once that is done, does not require any code change - but rather using one of the available fasttext patches - so that string output is inherently faster besides your BASIC logic.
Once those 2 speedups are done, you should be running around your maze.
Quote from: Fabrizio Radica on 16:38, 03 October 18
Now i would like to play music, but it's not so simple in basic. ::)
if you want to play a simple tune in basic, just put some data statements somewhere for the music notes, make a small function (gosub) that reads one and ouputs the notes. call it every 50th of a second with the every command. you can speed up or slow down the actual music using a counter, eg: every 50th of a second gosub blah, blah most of the time will just subtract the counter and return. You can tailor the counter to be any value to calibrate your data element to time, eg: 1 data element read = 1 second? Remember don't block the basic program by having a simple busy loop within the every function, but rather just return if you want to do nothing vs read and output the next notes.
Oh, nice little project... I'm still stunned what is possible in Locomotive Basic if done properly. This would have been a GREAT type-in back in the days.
Too sad the BAS file is not on the DSK.
Quote from: zhulien on 07:02, 05 July 21
if you want to play a simple tune in basic, just put some data statements somewhere for the music notes, make a small function (gosub) that reads one and ouputs the notes. call it every 50th of a second with the every command. you can speed up or slow down the actual music using a counter, eg: every 50th of a second gosub blah, blah most of the time will just subtract the counter and return. You can tailor the counter to be any value to calibrate your data element to time, eg: 1 data element read = 1 second? Remember don't block the basic program by having a simple busy loop within the every function, but rather just return if you want to do nothing vs read and output the next notes.
You really don't need to do anything that complicated in Locomotive BASIC, you can just use ON SQ to have your subroutine called when there is a slot free in the relevant sound queue and BASIC itself will take care of avoiding the music from blocking the rest of the program.