Forum Replies Created
-
AuthorPosts
-
It never shows up, and I get weird visual glitches (hovering the mouse over menus causes them to flicker) until I restart Ted. Again, using the side Files panel works fine, this only happens using “File/Open”
Here’s a video of what happens:
https://dl.dropboxusercontent.com/u/446189/monkey/tedFileOpenBug.mov
Opening a file from the “Files” side panel works fine, it’s just when I use the file open dialogue that the file refuses to show until I restart Ted2.
Even doing “open project” doesn’t work until Ted is restarted.
Monkey2 1.0.5, OS X El Capitan 10.11.6. But I’ve been having this issue for quite a while with previous versions.
I wasn’t sure what the state of Ted was in for OS X yet, so I never filed a bug.
Yup, I’ve been using Mollusk as the ide.
I haven’t had a lot of luck with Ted2 in OS X. If I run the Monkey2 (Macos) file under the main folder I can’t even open a file. Running ted2_macos under bin gets me a little further, but not much. I can open files, but they don’t show until I close Ted and reopen it.
I’m checking the same error now with Ted2 debugger running, pretty cool!
Thanks!At the moment I’m just trying to learn, and this seemed like a good “stress test” for the technique. I had never used Generics before, and I like objected oriented style a lot, so this felt like a gap in what I could do.
The particular case that prompted me to use this (not my test example code) can be solved with casting, but it’s a method that would be called a lot and I’d rather avoid casting if possible.
My next step is to learn interfaces properly. I understand how they work, but I’ve never thought of a practical situation where I’d rather use interfaces than classes. Also keep in mind that I’m an artist, not a programmer, and was never formally taught any of that, so I really appreciate that M2 is simple enough for me to learn it but still offers those possibilities.
Thanks!
Yes! That’s exactly what I’m looking for.
Thanks Mark, I also ran into the cyclic error when I tried something similar and thought it was actually invalid.
That’s great, thanks! I’ll dig into that gameobject code and see how I could adapt it as soon as I find a bit of time again.
Just out of curiosity, I see that you added a lot more classes and stuff, but has the collision code changed much since last month’s commit (which is what I’m using currently)?
I think I’ll go with a “transform” object just to keep that stuff separated from entity events and components, and I’ll handle the transform inheritance and collisions through the transform class. Thanks for sharing!
So I’ve found a little bit of time to play with the collision module, and I have to say it’s working great!
My next step is to try to use this with my own entity system. In my old one, each entity used to have a “Transform” object that provided much of the functionality you already have in tlBox, like coordinates, dimensions, moving with collision, etc., so I’m going to just use tlBox instead this time.
There’s one little thing I wanted to ask what’s the best way to implement: hierarchies, so that moving the parent moves all its children as well. Notice that in this case, objects need to store their local coordinates, and then calculate the world coordinate before they can do anything useful.
Should I add a step somewhere that adds the coordinates together on every frame before displaying and checking collisions? Os is there a better, built in way to do that?
Thanks!
P.S. Here’s a quick test I did to get my feet wet:
Monkey123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293#Import "<timelinefx>"Using mojo..Using std..Using timelinefx..Const BOX := 0Const CIRCLE := 1Const POLY := 2Function Main()New AppInstanceNew ColTestApp.Run()End' *************************** Window ***************************Class ColTest Extends WindowField player := New Entity( 200, 240, 40, 40, CIRCLE )Field box := New Entity( 400, 240, 100, 100, BOX )Field circle := New Entity( 300, 360, 50, 50, CIRCLE )Field poly := New Entity( 320, 100, 50, 50, POLY )Method New()Super.New( "ColTest", 640, 480 )EndMethod OnRender( canvas:Canvas ) OverrideApp.RequestRender()player.Update()For Local e := Eachin Entity.alle.Draw( canvas )NextEndEnd' *************************** Entity class ***************************Class EntityField collider:tlBoxField speed:= 5.0Field result := New tlCollisionResultGlobal all := New Stack< Entity >Method New( x:Double, y:Double, width:Double, height:Double, shape:Int )Select shapeCase 1collider = CreateCircle( x, y, width )Case 2Local verts := New Float[]( 0, 0, 1, 1, 0, 2, -1, 1 )collider = CreatePolygon( x, y, verts )collider.SetScale( width, height )Defaultcollider = CreateBox( x, y, width, height )Endall.Add( Self )EndMethod Update()Local vel := New Vec2fIf Keyboard.KeyDown(Key.Up)vel.Y -= speedElseif Keyboard.KeyDown(Key.Down)vel.Y += speedEndIf Keyboard.KeyDown(Key.Left)vel.X -= speedElseif Keyboard.KeyDown(Key.Right)vel.X += speedEndcollider.Move( vel.X, vel.Y )For Local e := Eachin allIf Not ( e = Self )result = CheckCollision( collider, e.collider )PreventOverlap( result )EndNextEndMethod Draw( canvas:Canvas )collider.Draw( canvas )canvas.DrawPoint( collider.WorldX(), collider.WorldY() )EndEndThanks, I was thinking about settling with something like that.
Also, to help me keep development folders for modules outside M2’s folder, I made this shell script that performs some basic checking, clears the module’s folder inside M2, copies the new files to the appropriate folder and compiles it, all in one easy command. I realised this would be useful since I had to run mx2cc anyway to compile the module, even if M2 supported symlinks.
Hopefully this can be useful to someone else:
https://github.com/DoctorWhoof/makemod/blob/master/makemod.sh
I would love if someone with experience in shell scripts takes a look at this for anything that could be improved, especially safety (my first versions used to wipe the entire modules folder when no arguments were given…)
I don’t think it’s a good idea to create a pixmap and an image from the pixmap every frame specially of that size
Agreed, if all you want to do is draw to a texture, try using an Image Canvas. There’s an example in the Bananas folder.
https://github.com/blitz-research/monkey2/blob/master/bananas/rendertoimage/rendertoimage.monkey2
Also, make sure you use the TextureFlags.Dynamic flag on that texture when drawing to an image canvas that is updated every frame.
Those are great, thanks! It would be nice if the Monkey 2 page had some sort of “learn” section with links to examples like these.
I, for instance, had no idea you could create timers like that.
Me, me! I want a heart too!
Of course when you use type inference like this you always have to assign a default value to the variable, but I feel like that is actually easy to understand when you look at someone else’s code.
Oh, and I’ve been using Mollusk as the IDE. Doesn’t officially support M2 yet, but it works pretty well already.
I need an editor with % $ and and # keys mapped to :Int :String and :Float
You may wanna try using := for variable assignments, like:
Monkey1234Field name := "Object" 'This is a stringField speed := New Vec2f 'This is a Vec2<Float>Field health := 100 'This is an IntField damage := 10.0 'This is a FloatAlthough it’s one of those things you don’t forget once you learn it, I feel like it would be a more intuitive/familiar design if instead of using “New AppInstance”, the command was “Mojo.Init()” or “App.Init()” or something like that.
It would be cool if the App.Run() ran automatically somehow as well. Monkey 1’s simplicity of use is a good design target for me.
Actually, I wonder why Mark didn’t create an App class that handles the Window and all the initialization like it does in M1. The new way offers a lot of control, but is also more complex and has more room for error. I feel that it could be an option alongside a simpler M1 style App class as the main option. Maybe it’s planned for the future?
-
AuthorPosts