ReadPixels/WritePixels
Community Forums/Monkey Talk/ReadPixels/WritePixels
| ||
| Says this can only be done in the OnRender section of code... Anyone else find that odd? |
| ||
| I think the reason for this is when OnRender is called certain states are there to allow rendering, in OnCreate and OnUpdate they arent. Basically OnRender is there for all drawing stuff to be called to make it compatible with all platforms. |
| ||
| The reason is because of threading, Graphics are done in one thread while everything else is done on a different one. and even if the specific target does not support threading, it's done just to keep a consistency with the language. you could, if wanted to, do everything on the "OnRender"/state Thread and not use the "OnUpdate". Threading makes it obviously faster to process and makes it a faster frame rate game. |
| ||
| The reason is because of threading, Graphics are done in one thread while everything else is done on a different one. As far as I know, if that would be true, this will make games to be rendered wrong. I mean, if classes are being updated while the rendering is being commit, how can you handle objects positions etc on a reasonable, synced and blocking free way? |
| ||
| whether you agree or not makes no difference, the fact is that OnRender and OnUpdate are done on separate threads and is the only reason for for the OnUpdate and OnRender requirements. |
| ||
| ehm. not. to begin, there's no threading on Javascript. to continue theere's no thread syncing on the c++ target nor in the c++ GC. also, why should be used if onupdate and onrender are obviously not executed in parallel? |
| ||
| *** shakes head **** you did read this from my post : ...and even if the specific target does not support threading, it's done just to keep a consistency with the language... but I am no expert, so what's your explanation? |
| ||
| As far as I know there is no threading in monkey? At least not in the versions I used (v42 and earlier)... |
| ||
| I am probably mistaken as I glanced through the module. but I believe it's all in the Brl Module on the newest Monkey versions. [edit] I think I am confusing the ability of the game running in threads with the actual game using events. so excuse my ignorant comments :). |
| ||
| there is a threading module, but it will not work with the GC. not really recommended for use. the reason the read/write is in the OnRender is because Mark dumps the image's heap memory and keeps the image in video memory. therefore, it can only be accessed during a valid context. it doesn't HAVE to be this way. miniB3D stores textures as pixmaps, so that data can be read anytime. |
| ||
| but I am no expert, so what's your explanation? It's as easy as it gets. Some platforms such as Android or XNA are designed to be event based and encapsulate the event loop, so you can't just Flip() whenever you want.Then, another way to see this is that, if render and update were executed using threads, that would mean that they are executed at the same time. Imagine that you're rendering something, and while you call the DrawImage(miImage,X,Y), the X value changes while this variable is inside the drawing routine, becouse the update process in another thread is modifying it. Also, imagine you're in the middle of the rendering of all "Enemies" inside your enemies List, while the Update has cleared the list (in the middle of the process), etc etc... It would be VERY VERY complicated to make any simple game in monkey if updating was not executed before rendering instead of being executed while rendering. As they have to be executed sequentially, the usage of threads for this task would be an overengeniering of the engine and a waste of resources, with the only benefit of making the Mojo source codes a lot harder to maintain while you grant they woudl perform a lot worse becouse of the internal suncing and blocking operations that would be required on the garbage collection area. (compared to current basic but effective mark and swap on C++ as an example) EDIT: That said, event-based systems on small devices are a very good way to build an efficient processing time sharing. The "pauses" when the update has been done and the render do not need to be performed yet can be used by the OS to process background tasks and daemons without requiring additional processing units. That's sort of the same approach as the IBM Time Sharing Option for mainframes, but addapted to low power and small processing systems such as phones or SOC based devices with a limited number of processing units. It's like they are attending several processes in the same way TSO system attended several user requests. I hope this is understandable... I'm a bit sparse, too much time coding and my English capabilities are not at their best |
| ||
| Just want to add that Javascript has threading; Workers. |
| ||
| Worker's are not threads. They run on threads, but they're isolated and can't diretly share data between them unless converting to/from JSON and using the main script file as a sort of data-anchor to share the messages being sent with postMessage. This is a good approach to make javaScript safer when multithreading but it is VERY limited and definitively not used for Monkey OnUpdate, OnRender, etc. |
| ||
| I see workers as an improvement of traditional threading forcing good practicee same with Android using their U Ithread as sort of main thread. Synchronisation are always expansive and should be minimal nonew or next to none. JSON makes up for the perfect IPC even if it might seem expansive at 1st sight. If using main thread as a data-anchor is questionable it fill certainly change in the future to become the best possible concurrency model. Graphics need of course not any thread but a steady heartbeat, I guess JS have a very special solution for just that outside of workers as it is now. |
| ||
| Yes, well, it is at last argueable how the fact that ANY data passed to a worker needs to be comverted to a string-based format (very expensive) and copied (even more expensive) is a good way to do threading. Threading should allow data to be shared instead of data to be copied only once, in one direction, and forcing a conversion/unconversion to a bloated string based format that needs to be parsed back again. A good threading approach would be the implementation of actors, to name one. Even a parallel loop implementation would be much better in order to add threading to the language. |
   |