@rogloh said:
... Be good to locate that so it's reliable/not broken on flexspin but I know it's someone else's codebase.
To be fair to the original author, Kye, he wrote it in Spin1 for the Prop1. It's since been ported to Spin2.
Yes I noticed. There probably is some sort of timing dependency built in there somewhere that varies depending on the compiler. I'd expect it to be in the lower level part that touches the SD card, not the FAT part.
@Rayman said:
Got wall tiles working in exmem. This is a big step. Allows for actual game...
Had to rotate wall tile images 90 deg CCW to make simple...
Guess soon time to work on sprites...
Havent' tried this latest version but I found that after a bit of walking about for a while in the map the two screen side by side halves started to diverge into noticeable separate windows. Might be some co-ordinate error accumulation over time causing rendering issues..
Yeah they seem to be getting out of sync over time when you navigate the map for a while - doesn't show up immediately but doesn't take long to happen either.
@Rayman said:
Think will try to put floor tiles in exMem too. Need to read in single words for that one.
Guessing should use: R_READWORD = %1001 << 28
But, don't really know how or why...
Is better in any way from readburst?
Is the usage the same?
They are different.
You can choose to read individual words into the mailbox data location itself, or you can read a burst of multiple words into some arbitrary specified HUB address. It's all documented. If you have consecutive words to read it'll be a lot faster to use the burst method, because every mailbox request operation incurs the polling and address setup overhead. But for a single item being read it's marginally faster to use a single word read over a burst. If required there is also the atomic Read-Modify-Write operation possible too using new data and a bitmask in the second and third mailbox parameters.
Just added AI generated splash screen to show at start up.
Instead of using a VAR for display buffer, now using this file as an embedded bitmap.
It just gets written over when game starts.
Nice to have it showing something at t=0.
Unfortunately, my monitor is taking a few seconds to think about the VGA signal it's getting before displaying it,
so had to add a delay so can actually see the splash screen.
Fixed a bug with floor map. Seems it was missing a couple rows.
Also, looked to see what happens if there are no interior walls, so all floor cast.
It is not good.
But, this works:
fMap byte "BBBBBBBBCCCCCBBBBBBB"
byte "B C B"
byte "C C B"
byte "C C B"
byte "A C B"
byte "A C B"
byte "B B"
byte "B C B"
byte "C C B"
byte "F AAAAAAAAAAAAAAAAAB"
byte "E D B"
byte "F D B"
byte "D D B"
byte "B D B"
byte "B D B"
byte "B D B"
byte "B D B"
byte "B D B"
byte "B D B"
byte "BBBBBBBBBBBBBBBBBBBB"
@Rayman said:
Ok, reading words from exRam to do floors is not going to work.
It's just too slow and sometimes most of the screen is tiles.
You may be able to make use of the request list feature if you have a group of items stored in PSRAM (like tiles or sprites) that need to be read to hub. You can prepare a list of memory addresses and submit it to the driver and it will go off in the background and retrieve them for you (or write them to PSRAM). If you can overlap this with other non external memory work to be done by the COG you can get better utilization in the code. It may or may not be of use in this case, but still useful to be aware of.
@Rayman said:
Unfortunately, my monitor is taking a few seconds to think about the VGA signal it's getting before displaying it,
Yep, so typical, the hardware will be sync'ing in a couple of frames but the management software inserts a couple of seconds of blank screen just to be annoying.
Started implemented sprites.
Now have one, single pixel wide sprite going.
Seems if make sprites 64-pixels tall, then can reuse the wall drawing subroutine to draw the sprites.
This is a huge speed benefit.
Now implementing sprite calculations in another cog (still one left for audio).
QVector instruction turns out to be very useful there:
DAT
org 0
SpriteEntry
mov ptra,pPlayer
mov ptrb,pSprites
SpriteLoop
waitatn
rdlong fplayerx,ptra[0]
rdlong fplayery,ptra[1]
rdlong fspritex,ptrb[0]
rdlong fspritey,ptrb[1]
'calc angle and distance to sprite (fixed at (256,256) for now)
mov fspritex, #256
sub fspritex,fplayerx
mov fspritey, #256
sub fspritey,fplayery
qvector fspritex,fspritey
getqy spritearc
shr spritearc,#16
mul spritearc,##ANGLE360
shr spritearc,#16
getqx dist 'distance to sprite
'mov spritearc,#200
'mov dist,#100
wrlong dist,ptrb[2]
wrlong spritearc,ptrb[3]
jmp #SpriteLoop
pPlayer long 0
pSprites long 0
fspritex long 0
fspritey long 0
spritearc long 0
fplayerx long 0
fplayery long 0
dist long 0
fit $1F0
Perhaps another COG allocated can help speed it up. Why does EXMEM need two COGs? EDIT: sorry misread that (2) meaning 2 cogs. But can you allocate another COG? Polling the USB keyboard might be possible in your video COG during blanking if you can do it in PASM2 instead.
Could increase graphics cogs from 2 to 3, but not enough. 4 might be, but then sound might be difficult...
Could also drop floor casting, but don't want to...
Was reading that Doom ran at 35 fps. Should be able to match that...
Comments
Yes I noticed. There probably is some sort of timing dependency built in there somewhere that varies depending on the compiler. I'd expect it to be in the lower level part that touches the SD card, not the FAT part.
That's possible too. My fix up in bashed3 wasn't exactly thorough.
Got wall tiles working in exmem. This is a big step. Allows for actual game...
Had to rotate wall tile images 90 deg CCW to make simple...
Guess soon time to work on sprites...
Havent' tried this latest version but I found that after a bit of walking about for a while in the map the two screen side by side halves started to diverge into noticeable separate windows. Might be some co-ordinate error accumulation over time causing rendering issues..
Interesting… there are two cogs, one for each half so suppose that is possible…
Might need better coordination…
Guess needs more testing.
Yeah they seem to be getting out of sync over time when you navigate the map for a while - doesn't show up immediately but doesn't take long to happen either.
If the symptom was one vertical line being wrong in center of screen, that was a bug, fixed in latest version above...
Think will try to put floor tiles in exMem too. Need to read in single words for that one.
Guessing should use: R_READWORD = %1001 << 28
But, don't really know how or why...
Is better in any way from readburst?
Is the usage the same?
Guess floor tiles in exMem is pointless unless also add a map so can have several floor tiles in the map...
They are different.
You can choose to read individual words into the mailbox data location itself, or you can read a burst of multiple words into some arbitrary specified HUB address. It's all documented. If you have consecutive words to read it'll be a lot faster to use the burst method, because every mailbox request operation incurs the polling and address setup overhead. But for a single item being read it's marginally faster to use a single word read over a burst. If required there is also the atomic Read-Modify-Write operation possible too using new data and a bitmask in the second and third mailbox parameters.
Ok, reading words from exRam to do floors is not going to work.
It's just too slow and sometimes most of the screen is tiles.
But, was able to add a floor tile map so can have several different floor tiles.
This example is with four floor tiles in HUB RAM.
Think there is room at the moment for 12.
But, there are still things to add like sprites and sound.
Think sprites can be in exRam, because they work a lot like walls. So, grab 64 pixels at a time.
Sound can probably be in uSD.
Just added AI generated splash screen to show at start up.
Instead of using a VAR for display buffer, now using this file as an embedded bitmap.
It just gets written over when game starts.
Nice to have it showing something at t=0.
Unfortunately, my monitor is taking a few seconds to think about the VGA signal it's getting before displaying it,
so had to add a delay so can actually see the splash screen.
Fixed a bug with floor map. Seems it was missing a couple rows.
Also, looked to see what happens if there are no interior walls, so all floor cast.
It is not good.
But, this works:
fMap byte "BBBBBBBBCCCCCBBBBBBB" byte "B C B" byte "C C B" byte "C C B" byte "A C B" byte "A C B" byte "B B" byte "B C B" byte "C C B" byte "F AAAAAAAAAAAAAAAAAB" byte "E D B" byte "F D B" byte "D D B" byte "B D B" byte "B D B" byte "B D B" byte "B D B" byte "B D B" byte "B D B" byte "BBBBBBBBBBBBBBBBBBBB"Guess that's OK.
You may be able to make use of the request list feature if you have a group of items stored in PSRAM (like tiles or sprites) that need to be read to hub. You can prepare a list of memory addresses and submit it to the driver and it will go off in the background and retrieve them for you (or write them to PSRAM). If you can overlap this with other non external memory work to be done by the COG you can get better utilization in the code. It may or may not be of use in this case, but still useful to be aware of.
Yep, so typical, the hardware will be sync'ing in a couple of frames but the management software inserts a couple of seconds of blank screen just to be annoying.
Started implemented sprites.
Now have one, single pixel wide sprite going.
Seems if make sprites 64-pixels tall, then can reuse the wall drawing subroutine to draw the sprites.
This is a huge speed benefit.
Now implementing sprite calculations in another cog (still one left for audio).
QVector instruction turns out to be very useful there:
DAT org 0 SpriteEntry mov ptra,pPlayer mov ptrb,pSprites SpriteLoop waitatn rdlong fplayerx,ptra[0] rdlong fplayery,ptra[1] rdlong fspritex,ptrb[0] rdlong fspritey,ptrb[1] 'calc angle and distance to sprite (fixed at (256,256) for now) mov fspritex, #256 sub fspritex,fplayerx mov fspritey, #256 sub fspritey,fplayery qvector fspritex,fspritey getqy spritearc shr spritearc,#16 mul spritearc,##ANGLE360 shr spritearc,#16 getqx dist 'distance to sprite 'mov spritearc,#200 'mov dist,#100 wrlong dist,ptrb[2] wrlong spritearc,ptrb[3] jmp #SpriteLoop pPlayer long 0 pSprites long 0 fspritex long 0 fspritey long 0 spritearc long 0 fplayerx long 0 fplayery long 0 dist long 0 fit $1F0Lots more to do, but looking achievable
Made a little map of what the cogs are up to in order to better synchronize things.
Main cog is very underutilized. May put the USB polling somewhere else and have a second spare cog...
Guess facing the unfortunate truth that adding transparent sprites is going to half the update rate from 60 fps to 30 fps.
Problem is that sprites can take up most of the screen and so takes a long time to draw....
Perhaps another COG allocated can help speed it up. Why does EXMEM need two COGs? EDIT: sorry misread that (2) meaning 2 cogs. But can you allocate another COG? Polling the USB keyboard might be possible in your video COG during blanking if you can do it in PASM2 instead.
Could increase graphics cogs from 2 to 3, but not enough. 4 might be, but then sound might be difficult...
Could also drop floor casting, but don't want to...
Was reading that Doom ran at 35 fps. Should be able to match that...