I’ve just put my working code on codea community: DungeonCube
It works fine at my end and I would be grateful to know if it works okay when downloaded.
I have a variety of questions based on the output of the code which I’m not quite understanding.
I think I’ve got my head around classes and class inheritance, I think I’m okay with basic 3d work and I’ve been experimenting with moving things around.
The first thing that I don’t understand is that based on my interpretation of the code that I’ve written, the randomised block sections that you should see moving up and down and spinning around, shouldn’t be doing so simultaneously. One should rise then another then another etc then one should spin then another then another etc and then they should then fall one by one…it’s really nice that they do move (almost) simultaneously but I don’t understand why this is happening, could anyone shed any light on this for me in terms of how codea is processing the code or in terms of my own misinterpretation of how the code is working? I appreciate there is a lot of code, the code dealing with the general movement is mainly in the tab “localrandomrotation”
I’ll leave the aspect of camera positioning for a little later…
@TheAbstractMan - it could take me hours just to figure out the sequence of events, but if you want the random blocks to move sequentially, why not keep a table in MazeBuilder that holds a list of sections to be moved, and get Codea to move the first one, remove it from the table, and so on. You can add more to the end of the table as you wish.
I noticed your MazeBuilder:Retabulate function is quite dense and hard to read because it continually uses self.rant[1] for table indices. You will find your code much easier to read - and it will actually run faster (because locals are faster than table references) - if you put this at the top
local x,y=self.rant[1].x, self.rant[1].y
-- now just use x and y in the rest of the function, eg
a1=self.Dun(x,y)
I would also make all the variables in that function local, unless they need to be global, otherwise they will overwrite variables of the same name anywhere else in your code.
As always, many thanks for your advice @ignatz. I will implement changes and learn… However, I’m not actually wanting a sequential movement, it was just that I was expecting it. I was very surprised to see everything moving simultaneously and couldn’t understand why it would do this based on my understanding of how the code was being processed. I’m interested to know how codea is processing code, as it appears that multi threading is occurring…but obviously I haven’t implemented any multithreading within my code…I.e. How does codea handle classes and instances of classes?
@TheAbstractMan - Codea (or rather Lua) doesn’t multi-thread, it runs sequentially. Your movements appear to take place over a number of frames, and Lua is simply running each class instance’s Randomlocalrotation in each frame, so each instance gets a chance to do a (partial) movement, making them all move together.
It seems quite slow, though, so you might want to optimise it when you have it working fully.
Yeah, I’m feeling stupid now! My brain’s so addled! I’ve been completely ignoring the counter that I put in and just assuming everything’s going off the self.seed variable. Sorry.
I was pondering a similar question the other day - my excuse is that it makes all the maths that I’ve studied relevant within some real world (albeit virtual!) situation, otherwise I’ve just wasted 35 years on abstraction. Hey ho.
So, onto my next question. I’ve asked about this before and didn’t really clear things up in - my mind anyways. I’ll choose my words very carefully here: It’s to do with the screen positioning of the point of focus of the camera for 3d viewing. In DungeonCube I’ve deliberately left the parameters in as opposed to putting in a touch function, to illustrate my point. The camera focus irrespective of where it is pointing (I.e 0,0,0 or 130,45,67 etc) positions the viewer’s focus at the centre of the observable screen, and any perspective effects are derived from this position of centrality. Now it must be possible to move this centre point of viewer’s focus to a different position on the screen because codea is doing so every time the output/parameter screen is toggled on and off…I.e. You can see the central point move from the centre of a square (I.e off to one side, when the output window is visible) to the centre of the full screen rectangle (when the output screen is hidden). The last time I asked, because I was asking within the context of multi screens, I was directed to some split screen octahedral code produced by A Stacey, but it appeared that even though he was producing two simultaneous views within two clipped screens, the actual viewer’s point of focus was still the centre of the actual screen for both, which meant that the view within each of the clipped screens wasn’t really giving a coherent sense of double vision as it were…because I would assume that really for each clipped screen, one would wish for the viewers point of focus to be the centre of each clipped screen as opposed to the centre of the actual screen. Does anyone know how to alter this central positioning so that for example, the perspective effects are being calibrated with respect to the bottom right hand corner of the screen for arguments sake or any point that one wishes to choose? Hope this makes sense…
@TheAbstractMan - if by “point of focus” you mean “the point at which the camera is looking”, you get to set that in the camera function, so if you have two viewing windows, they can be looking in different directions, by altering the camera settings.
No @ignatz, it’s not where the camera is looking, it’s how the view of the camera is centralised for the viewer/user of the iPad screen that I’m interested in and how to move that centralisation point to anywhere on the screen. I go back to my example of the output screen toggle. With the output screen present, the view is centred on the horizontal midline of the ipad screen but to the right hand side of the vertical midline of the iPad screen, whilst with the output screen hidden, the view is centralised about the exact mid point of the iPad screen. This demonstrates that it must be possible to move the centralisation point of the view…because we have here an instance of it happening.
@TheAbstractMan - the translate command moves the centre (0,0,0) point to any position in your 3D world. You can then draw everything there. So if you want your camera centred on the right side of your world, translate to the left, draw everything, then translate back to your original position again (popMatrix does that for you).