Forum Replies Created
-
Posts
-
It’s a bug, will fix!
Stack.Backwards() is already in there.
Specifically, are stacks quicker when adding objects to them as compared to a list?
Generally much faster – adding to a List requires the extra allocation of an internal Node object.
A stack is basically just an array that grows as necessary, so unless the stack needs to grow adding to a stack is just blah[i]=obj;i+=1. When the stack grows, it grows by capacity*1.5 so eventually the stack capacity ‘settles’ to the max objects the stack can hold.
The downside of a stack is that to remove an object, all elements after the object must be shuffled up, like removing a value from an array.
But the overhead here is similar to List.Remove() which a lot of people seem to use, which does a linear search to find the node containing the object. The only time List is a win when removing is if you can use it.Erase() while manually iterating through values.
Even if you can do this, Stack is usually still a win as the reduced overhead of adding and iteration is worth it. To iterate through a list requires following ‘next’ pointers around, while iterating through a stack is just like iterating through an array, ie: very fast.
As for whether it’s worth it, as always ‘it depends’. If you’re not using large amounts of objects, or if the cost of iteration etc is ‘dwarfed’ by per-object processing cost, then probably not. It may not be worth it for your project, but I think it’s something to consider for future additions.
Also, you can just select the code and set it to ‘preformatted’ via the PARAGRAPH dropdown menu.
That’d work.
Also, not sure if it’s docced yet but each view also has a ‘Style’ object that has DefaultColor and DefaultFont properties. These are set just before OnRender is called, so you can provide a default font and color for OnRender, eg:
1234Method New() 'Window ctorStyle.DefaultFont=...Style.DefaultColor=...EndSorry Mark, I have another one.
No problem – I want to get the bugs out ASAP.
It is actually working as expected though. The program successfully compiles and runs but generates a ‘memory access violation’ due to the null pointer, so it’s not the compiler crashing at least. And on the 97% finished version of Ted2 I’ve got running here, the debugger pops up and you can actually see where the error is – what luxury!
When I remove the canvas:Canvas field from the Class, the program compiles
Doesn’t here – I get ‘identifier canvas not found’ (as I would have expected).
I was trying this to see if I can get to the canvas in the window.
You can’t. The render canvas is ‘special’, and I want to make sure it’s state is not changed behind my back, and that I can change it on the fly if necessary (ie: you may not always get the same canvas in ‘OnRender’) for future features.
You can always render to an ‘image canvas’ and just DrawImage that to the render canvas in OnRender. This allows you to ‘draw’ at any time, and to apply funky effects at OnRender time like fade out etc. I’ll probably end up adding a CanvasView that does just that eventually, but the whole view system needs cleaning up and doccing before that’s realistic, so that’s an after V1.0 thing.
seeing duplicate identifiers
Actually, that could be a bug.
Files should be able to cyclically #import each other – basically, only the first #import of a particular file actually does anything, successive #imports of the same file are ignored (in theory).
If it happens again and you can reproduce, please post some sample code!
A module is not a file – it’s a bunch of files contained in a top-level directory inside ‘modules’.
Files within a module can reference each other no problem.
This was kind of confused in monkey1 – there’s what people think of as the ‘mojo’ module that contains all the graphics, audio, input etc stuff (in mostly separate files), but there is also the mojo ‘module'(!) which is the file called ‘mojo.monkey’.
But in mx2, a module is just a bunch of related files that you stick in the same dir.
I suggest having a look at the modules/mojo folder and files to get an idea of how it works. Note that image.monkey2 can reference stuff declared in texture.monkey2, and vice versa if necessary. They don’t even have to #import each other (although they can if they want) – all the #importing of monkey2 files is done in the main mojo.monkey2 file, sort of like a ‘makefile’.
Also note that each file starts with a ‘Namespace’. This is roughly equivalent to the namespace mx1 implicitly creates for each file (or ‘module’!). But it’s way more flexible, because it’s multi-level AND has nothing to do with the actual file path, meaning you can move files around freely without breaking stuff! How I’d love to split up mojo2’s graphics.monkey file…
There should also be a ‘<>’ icon on the ‘visual’ toolbar.
> When your initialising your Singleton your also not storing your initialised instance:
Actually, he is…
Are you using the latest emscripten? Latest GL drivers etc?
I’m on 1.36 here and all is OK, but to be honest, problems with emscripten on linux don’t surprise me all that much.
If I launch the monkeyroids.html file from a file manager it will crash the browser
You wont be able to run emscripten apps from the file manager reliably – they need to be served, hence the use of mserver. Any crashes here are definitely the browser’s fault – it’s just a web page with some javascript in it after all!
To load ‘non-assets’ at runtime in emscripten will require the use of a httprequest, possibly via an eventual http:: stream.
TODO…
Will look into it!
There is probably some scope for reducing exe sizes – you could rebuild everything in release mode optimized for size instead of speed for example – but I can’t see it making a huge difference and I wont be doing this by default.
Much of the size will be a ‘one off’ hit, eg: the mingw static libs and SDL etc. Adding code shouldn’t blow things up tooo dramatically.
Creating a self extracting exe of ‘spacechimps’ gives me a 2M exe with I’m OK with.
Each module is physically ‘atomic’, ie: you either import all of it or none of it.
However, each file in a module can be in it’s own namespace so you can logically split things up within a module.
So you could choose to put everything in a single ‘rigz’ module, which users would import with:
#Import “<rigz>”
Then, if they wanted to ‘use’ just the collision stuff…
Using rigz.collision
Note that the other non-collision stuff in the rigz module is still available, only users will need to fully qualify symbols, eg:
rigz.system.Blah() ‘need this ‘coz we’re not Using rigz.system
The ‘Using’ just means they can skip the full qualification.
My advice for now would be to stick everything in one module. If you are using the lastest mx2 build, you will also need a ‘module.json’ file in the module dir that should have at least this in it:
1234{"module":"rigz"}Also, the Exception class has been removed from the monkey module in the latest update, mainly because it can be done in ‘pure’ monkey so doesn’t need to be in the ‘core’ module.
I could add this back to ‘std’ but it doesn’t really do much, basically just stores the ‘msg:String’ ctor param in a field.
