|
|
Post by johnno56 on May 20, 2020 21:25:14 GMT -6
As I was working my way through the "3.12" examples, in this case gfx/3dmaze, I came across this subroutine...
Sub LoadGrid(rows, cols)
f = FreeFile
FileOpen(f, "grid.txt", TEXT_INPUT)
For i = 0 to rows-1
s$ = ReadLine(f)
For j = 0 to cols-1
Map_Grid[i, j] = Val(Left(s, 1))
s = Mid(s, 2, Len(s)-2)
'Print "g[";i;", ";j;"] = ";Map_Grid[i,j]
Next
If EOF(f) Then: Exit For: End If
Next
FileClose(f)
End Sub
There is no error or problem per se, just a question...
The string variable, s$, is assigned the value of the file line read, right? But within the following For...Next loop, the s$, is referenced as just plain "s"...
I initially thought it was a glitch and changed all the "s"'s within the loop to "s$". The program did not behave any differently... I restored the routine to its original state. I'm not complaining but it left me a little confused... When, where and how, did rcbasic determine that the 'seemingly' integer variable "s" acquire the status of a string?
By the way, this is a brilliant demo... Reminds me a lot of Wolfenstein 3D...
|
|
|
|
Post by n00b on May 20, 2020 22:59:20 GMT -6
You only need the "$" when you first create the variable. Its optional every time you use it after that.
Glad you liked the demo.
|
|
|
|
Post by johnno56 on May 21, 2020 0:51:45 GMT -6
So... I would imagine that, after "s" has inherited the string status, avoiding the use of "s" as an integer would prevent RC from "spitting the dummy"? lol
Yet another question... The current 'map' is set to 15 x 11 'tiles'... Do you think that the game would lag if say the map was increased to 64 x 64 tiles? Reason: I just happen to have downloaded all Wolfenstein 3D maps (images) some years back, and I am curious as to whether or not, they can be used in 3D Maze. I also happen to have pretty much all of the textures as well. Each W3D map has a max size of 64x64....
Of course, before setting aside such a huge amount of time, researching the possibility of making a game using 3D Maze, would have to be done. If a game is too difficult, then just to see if the level map can be created, could be fun...
I will look at Level 1, assess how many textures are needed, then figure out how to convert the image of the level map to a text file... I may end up regretting this... lol
|
|
|
|
Post by n00b on May 21, 2020 6:15:34 GMT -6
So... I would imagine that, after "s" has inherited the string status, avoiding the use of "s" as an integer would prevent RC from "spitting the dummy"? lol Once you have made s a string you won't be able to change it until you either delete the variable or exit the function or loop it was created in. If you tried it would not compile. Yet another question... The current 'map' is set to 15 x 11 'tiles'... Do you think that the game would lag if say the map was increased to 64 x 64 tiles? Reason: I just happen to have downloaded all Wolfenstein 3D maps (images) some years back, and I am curious as to whether or not, they can be used in 3D Maze. I also happen to have pretty much all of the textures as well. Each W3D map has a max size of 64x64.... Of course, before setting aside such a huge amount of time, researching the possibility of making a game using 3D Maze, would have to be done. If a game is too difficult, then just to see if the level map can be created, could be fun... I will look at Level 1, assess how many textures are needed, then figure out how to convert the image of the level map to a text file... I may end up regretting this... lol You could make the map that large without lag. Making a full game from that is also possible. But it would be quite a bit of fun (ie. work).  |
|
|
|
Post by johnno56 on May 21, 2020 20:01:13 GMT -6
I think I will give the W3D thing a miss... At last count there were at least 62 wall textures alone... Admittedly they are all not in Level 1... but who plays a game with only one level? lol ... or perhaps using a more "spartan" tile-set? lol
|
|
|
|
Post by n00b on May 22, 2020 8:39:30 GMT -6
This can be made a little easier with a tiled map loader. But to make that we would first need an xml parser. I might tackle this once I am finished with the current project I am working on.
|
|
|
|
Post by n00b on Jun 1, 2020 0:41:44 GMT -6
I made some modifications to the raycaster to increase the size of the level. The problem I am still having is that I have a very flawed method of texturing the floors. I hid the lack of draw distance on the floor by designing the level to hide the clipping behind walls. Let me know what you think. Attachments:3D Maze Mod.zip (34.83 KB)
|
|
|
|
Post by johnno56 on Jun 1, 2020 2:51:34 GMT -6
No can do at the moment... My main drive pops up with "firmware" error message. Removed all drives and booted with a boot-able Linux Mint 19.2 usb. Same error... Hmmm... hardware? Created a Linux Mint 18 boot usb. No errors! My conclusion: Software has out-paced my current machine. For the time being, I am going back to Linux Mint 18, until I can upgrade my machine. In our current economic climate that may take some time... LM 18 is 'supported' unto 2021...
I have created a new installation and the browsers were one of the earliest installs... I will download your file but it may take a couple of days to get to it... I need more coffee...
|
|
|
|
Post by n00b on Jun 1, 2020 11:08:01 GMT -6
johnno56 I made some more modifications to it. The drawing distance is really far now and it keeps a decent frame rate. You could probably turn this into wolfenstein if you wanted. There is 2 grids being loaded now: grid.txt is the walls and floor_grid.txt is the floor. When you get a chance to look at it let me know if you have any questions. Attachments:3D Maze v3.zip (33.88 KB)
|
|
|
|
Post by johnno56 on Jun 1, 2020 16:32:27 GMT -6
Well, I have my machine functioning at some kind of normality... lol Still a lot of stuff to install... But the important stuff is done... Anyway... Back to the topic at hand.
I see you found the Wolf3D tiles... Cool...
Having a larger grid certainly has an impact on performance... Not quite as 'zippy' as your first edition.. But ran without error...
According to "grid.txt", your map is 40x28, but lines 7 and 8 of Maze3D.bas has the size set to 15x11. I tried changing it to 40x28 but it made no obvious difference. Modifying "player_MoveSpeed" on line 127 to either 6.0 or 8.0 took care of the speed but not sure as to the cost...
For a "2D dedicated" program RC seems to handle the Wolf3D scenery quite well. I won't be converting 'this' demo to sdlbasic... Poor thing will probably have heart failure trying to cope with the rendering... lol
Do you have any plans on taking this any further or was this a "see if it could be done" venture?
Regardless, of whether you continue or not, I think you have done a great job with this one... I wonder what other surprises are hidden within RC?
|
|
|
|
Post by n00b on Jun 1, 2020 22:04:34 GMT -6
I don't have any immediate plans to take this any further but I might use this rendering technique in a future project. There are more optimizations I could do to speed this up but it does at least show what rcbasic's rendering API is capable of.
As far as converting it to sdlbasic, it would probably be a little difficult because of how sdlbasic deals with rotation. It might have some extra math to account for the difference.
|
|
|
|
Post by n00b on Jun 2, 2020 9:29:55 GMT -6
I just tried out version 3 on my old laptop and I see what you mean by it being slow. It is the method I used for the floor in this example that is slowing it down. I am going to take another stab at it and try to speed it up.
|
|
|
|
Post by n00b on Jun 2, 2020 23:33:46 GMT -6
Try this out. I modified it so it draws the tiles for the level as it comes across them. Its a little flakey but it should have a much faster frame rate. Attachments:floor.bas (14.24 KB)
Maze3D.bas (13.73 KB)
|
|
|
|
Post by johnno56 on Jun 3, 2020 0:27:06 GMT -6
First try speed was still slow... But changed the player speed from 4 to 8... no change... It could be that because my system is not "fully up to scratch" might contribute to the cause... I suppose a simple (well maybe not so simple... lol) test would be, not to draw the floor at all. If memory serves correctly, wolf3D used single colours for the ceiling and the floor... Just a thought...
|
|
|
|
Post by johnno56 on Jun 3, 2020 0:35:47 GMT -6
Just tested by omitting the floor... Restored player speed back to 4... The demo ran quite smoothly... I would have to conclude that the floor is impacting on the speed but, because all this 3D stuff is over my head, I cannot offer a solution... Sorry.
|
|
