can GetPixels&Img.WritePixels do Dynamic Pixels?
Monkey Forums/Monkey Beginners/can GetPixels&Img.WritePixels do Dynamic Pixels?
| ||
| Trying to study on the makeup of Dynamic Pixel game engines (alpha maps, texture field manipulations, masks, pixel arrays which can update original texture data in draw, a few more expiriments and tutorials..) and anyway, could Monkey handle dynamic pixels or even render them like this game: https://www.youtube.com/watch?v=RuI67c1A71o&nohtml5=False I know games like liero and worms are possible, because you can update the pixels in the rendered img.pixelarray to it by writing it (the new array which has ben changed in x or y pixels at different lengths, width, locations, color values) im sure I could figure out how each unique color value means a different interaction with say a moving ball entity which can getPixels from a imgLandScape which is holding said values in an array and test overlap based on the ballImgEntity.x/y and rect bounds but that would be something id have to experiment with. Anyway, im semi-sorta-ehhhh able to understand the design concept behind all of this I was just wonderring could MonkeyX (or just Monkey with mojo 1) handle such a game? Even at a limited scale? (Yes I sorta-kinda realize the pixels are actual data points with rendering image information drawn on top of it usually in some form of array of data or values that are sometimes seperated into zones to cut down on checks I think, still trying to find a lot more material on this subject,) well thanks , I will go now... I am pretty sure tho that Monkey can handle a game like Storm2D for sure: https://www.youtube.com/watch?v=Ct5D14DQ9Lg&nohtml5=False although youd definately need to get into OpenGL. |
| ||
| My guess is that you don't want to be using it in real time much, and I think the render-loadimage pipeline would probably lead to some frame stuttering, but you could maybe get away with a 'catch-up' mode in which terrain deformed by an explosion gets redrawn and converted to a new permanent image, separate to the rendering of the explosion. But really, I'm just guessing. I've only ever used it for pre-rendered stuff at the start of a level. The best thing to do - unless someone already has deta\iled experience - is simply try it out and see how fast you can computationally create terrain images on your preferred target. |
| ||
| oh yeah for sure, I was told I need to figure out a system that only updates parts of the image when necessary. I'll try some experiments and see if I can figure it all out. |
| ||
| Nowadays computers are really fast. I am sure you can manipulate quite some data on the screen in real time. I have not done much of this stuff other then change a few blocks in real time in games like Space Invaders where the bombs/bullets destroy the concrete blocks on the bottom of the screen. And some other things. If you go the tilemap aproach and only modify the tile blocks that the lasers collide with ect. you can do a lot. I am not that of an advanced programmer but a game like storm 2d seems doable in MonkeyX+mojo1. It's about the bandwidth right? Not to sure about more complex things that I have little experience with like : Dynamic Pixels, alpha maps, texture field manipulations, masks. I thought that the next generation video cards had a speed of a terrabyte per second or so. Memory is getting faster to next generation. If you tile the entire map then modifying tiny parts of it is fast. I saw you posted in my tutorial thread to. Will take a look there to. Edit : Here something I made last year or so. It modifies image pixel data and draws it as a image on the screen in real time. http://monkeygameprogramming.blogspot.nl/2015/01/monkey-x-drawing-in-imageswritepixels.html |
| ||
| Thats what someone told me to do, split the map into tiles of atleast 32x32 grid squares and run checks/for loops(limited range check called manually from a changing element within a certain radius of itself touching certain zones...) against each one for changes within each one being marked as changed.. or something. Or 64x64, etc. I am going to study this a bit to see the best approach. |
| ||
| That sounds like the right approach. For a Worms-style game I would probably make an array of smallish (not too tiny, I think, but it can be a variable anyway) images covering the entire terrain, then just reload continuously as they changed. Of course classic Worms style doesn't even have to be framerate perfect. Pakz's example is nice, I was toying with the idea of trying something similar. But I should finish my current project first! Fun things to code are the bane of programmers who like to code. I can't help wondering if part of the success of game creator software comes from it being harder to go off on a tangent instead of sticking to the project... |
   |