Forum Replies Created
-
Posts
-
Looks good, it seems that it has potential. My estimations on this would be something about adding more details to the world, even the most simple low poly rocks would do.
But it depends on the mission goal, are you planning to create a full prototype from this? Or is it just for experiments?
From what I understand GL_NEAREST creates this pixelized effect, which is particularly good for retro styling.
From my perspective it would be a much preferred way to produce this effect in a post processing shader. Because that way you don’t have to mess with the underlying engine configurations.
I tried it today and it worked, I did not know it was possible.
I see that in all game examples everybody wants to use #Import instead, perhaps this helps with deployment.
12345678910111213141516171819202122232425#Import "<std>"#Import "<mojo>"Using std..Using mojo..Class MyWindow Extends WindowField _image:ImageMethod New(title:String="Simple mojo app", width:Int=640, height:Int=480, flags:WindowFlags=Null)Super.New(title, width, height, flags)_image = Image.Load("-> image path here <-")EndMethod OnRender( canvas:Canvas ) OverrideApp.RequestRender()canvas.DrawImage(_image, 0, 0)EndEndFunction Main()New AppInstanceNew MyWindowApp.Run()EndRegarding assembly compilations, considering that g++ is the standard compiler in every OS and platform, choosing a transpiler is much wiser decision to solve the problem of portability once and for all, going the assembly route would make no sense.
Regarding the 3D module, perhaps it makes sense to be developed. Monkey 2 is practically useful and stable enough to create stuff in it. 2D games are do work fine and get the job done, but the wow factor of 3D is missing. Gaming enthusiasts will better prefer 3D environments better, and this is unavoidable, the creation of the 3D module acts as a advertisement itself, the best form of advertisement is the proof of concept, the practical approach.
Community Split
I am not sure that there is such thing going on. Personally I have never used Blitz3D or Blitzmax, and I can’t feel it.
From my understanding the “split” occurs due to a feeling that there is some sort of historical continuation over all of these languages. But these languages differ, for example these changes are not only in the matter of how you write the syntax (i.e. Blitz3D->stuctured, Blitzmax->OO), it’s a holistic approach where everything counts, both technically and community wise.
For example if you say that Blitzmax was awesome but it needed a few updates. Forcing these changes to people would blew the language. For example these languages were conceptualized and designed to work in a specific way, and they fulfilled their purpose and were perfected. The fact that the languages remained unchanged is a proof that people still make cool stuff in them, because they would not have to change their existing skills and knowledge to keep up with the changes.
From my experience, introducing changes in an already working system is a risk and sometimes an ambiguous ROI. Even Microsoft who hires the best engineers in the world pereferred to write the Powershell rather than fixing the cmd. This is a matter of stability mostly.
Perhaps you could send the project zip to him, just in case there is something fishy going on, it would be easier to spot.
Binary Sizes
I haven’t put on thought on binary sizes before. The most worthless mobile phone (where you can get for 80 bucks) can have 8GB of memory these days. On the other hand dedicated PC gamers or PC professionals could have 16GB of RAM. For example on Windows 8.1 I open the task manager and I see 74 processes and 904 threads running on idle, and I use only 3/12GB of memory. I could guess that I would be able to run 90 games at the same time of 100MB each, to reach up to 9000MB. But you get the idea, my point is that technically these are manabeable file sizes for the current computer systems.
Just for proof, “CrossCode” (a PC game) in my drive is about 178MB and an Unreal4 tech demo is 38MB (with the other binary libraries adds up to 78MB). Practically people already execute big executables without even noticing, chances are that if you don’t tell them they won’t know.
___
Packing Stuff
Perhaps Blitzmax doing so, was done as a design choice back then, I have never used Blitzmax though. However if you consider what other game engines do, is that actually they use a Virtual File System. The most obvious VFS is a protected zip file but it’s the easy and lazy approach. Other than that, there could be some C based VFSs that would be wrapped easily in Monkey, perhaps even someone could create a custom VFS for Monkey. My point here is that packing can be managed either with a VFS or a third party tool (binary merge if the size is reasonable).
___
Compile Times
Actually how Blitzmax worked was conceptually different than Monkey 1 and Monkey 2. I am not a compiler specialist, but having browsed the repos a bit, I noticed that Blitzmax, generated assembly code directly, which explains the small file sizes and the fast compile times. Monkey2 on the other hand generates actual C++ code that is later on compiled to a binary application with the help of the standard g++ compilers. If you really mention that g++ compilers suck and are awfully slow you are right, but this is something we can do nothing about, because that’s how the universe works.
___
No Clear Roadmap
Perhaps that would help for communication purposes and to be in tune with the project, a Trello board would be a good idea. Although some information are mentioned in the blog, perhaps they are not in plain sight and need to be searched. Now, if there’s a way that the community would be able to make wishlists and vote for the best features (uservoice.com) this would make sense as well for communication purposes, how to connect development and requirements.
Cool stuff
Which modeler program do you use?
I have experience with Blender 3D but I would be interested to look at something else.There is Windows and Mac precompiled distributions.
https://blitzresearch.itch.io/monkey2What sort of errors do you get?
From my experience all the errors for me occurred by using a random MinGW version. On the contrary, this is the only recommended version.
Mingw-6.2.0 build tools for Windows
http://monkey2.monkey-x.com/monkey2-files/Also the bin must be set as a PATH variable (typing g++ on command prompt should display a compiler message).
This is somehow related to the nature of the problem, for example GUIs are based completely on event driven architecture. Another case where FP doesn’t fit is resource management (memory, network, hardware) where simply the paradigm collapses. I remember once doing some OpenGL with F# for fun and the code was totally imperative.
Functional programming is a different school of thought. For example in imperative programming languages you would consider an approach like “Firstly_DoThis”, “Secondly_DoThat” and so on, you put each statement after another where they would be executed sequentially. In functional programming languages you would consider doing something like this “GiveMeTheResult(ButFirstCalculateThis(GetSomeDataFromHere(), GetSomeDataFromSomewhereElse())).
The basic idea with this concept is that programs are considered to be consisted out of expressions (as “math expressions”) rather than sequential steps. This is why in lisp you see so many parentheses. In other functional programming languages as in F# or Scala the concept of “piping” have emerged to reduce the amount of parentheses.
It seems that development progress goes well.
There could be lots of projects out there that will give you an idea, for example I will mention this one:
https://github.com/ailisp/simple-guiVery interesting stuff.
Perhaps you could make a space trading game out of this experiment.
I see, in that case you would go for classic functions at this time.
This is a feature that does not exist in Monkey. You can get only
the most basic directives for preprocessor conditional logic.
http://www.monkey-x.com/docs/html/Programming_Language%20reference.html#preprocessor