|
Post by n00b on Mar 31, 2019 8:14:25 GMT -6
Hey johnno56 the game still seems to be running really fast. I do like the simplicity of the mechanics. Its kinda reminds me of solomon's key on the NES.
|
|
|
Post by johnno56 on Mar 31, 2019 15:22:25 GMT -6
Yeah... Tbird mentioned adding 'delta time' to address the speed issue. I think he maybe working on it...
In the meantime I am experimenting with different layouts and tilesets. Kind of torn between 640x480 (20x15 tiles) or 800x600 (25x18 tiles). What would you recommend? 32x32 tiles look nicer and 16x16 looks 'old school'. Both are nice... but... (this is the part where you are to advise which way to go... lol)
|
|
|
Post by tbird on Mar 31, 2019 18:50:38 GMT -6
This is what I got, was a little tricky because it's completely grid based, so somethings are a little goofy. For example I added delta time and smooth movement but if you land on a grid position and the player hasn't slid over the full 32 px then it won't register as being on the grid + or - 1, it works for the most part and only had a few anomalies, will have another look at another time. It's a good start for you, just adjust "speedx" and "speedy" to your liking, if "speedy" is really fast it makes it hard to get the jump over just right.
I think it has a decent feel right now, but please everyone try it out and make adjustments as necessary.
|
|
|
Post by n00b on Mar 31, 2019 21:26:10 GMT -6
I just tried this new revision and its much better in terms of speed. And johnno to answer on what would be a good tile size, I personally think 32x32 is an ideal tile size. While you can get more detail with a 16x16 tile size, you are going to be drawing 4 times as many tiles. I really do like the over look and feel of this game though. I think the only thing its really missing is some background music.
|
|
|
Post by johnno56 on Apr 1, 2019 4:22:46 GMT -6
I agree the "feel" of the movement is much better... Thanks tbird Ok. 32x32 it is... As to the "atmosphere" of the game, I am open to suggestions... ( I must warn you... I draw the line at Jazz and Rap... lol ) I am also looking into backgrounds as well... Although the "black" serves to make everything stand out, I think a little 'interior' decorating, could be a bonus... An open quick question.... Does RC have a command to extract images from a spritesheet? Just curious. No big deal if not....
|
|
|
Post by n00b on Apr 1, 2019 5:49:58 GMT -6
You can extract sprites from a sprite sheet with DrawImage_Blit() and DrawImage_Blit_Ex(). You should check out the other DrawImage functions as well. You can do more with them than you might think.
|
|
|
Post by tbird on Apr 1, 2019 7:10:10 GMT -6
Glad I could help! If you need any special effects let me know.
|
|
|
Post by johnno56 on Apr 1, 2019 15:14:50 GMT -6
n00b: I am familiar with DrawImage_blit() but have not looked at "_Ex()" as yet. Admittedly, I was looking for something like grab() or get(), but I will check out your suggestion. My idea was to load only one image file and "slice" and "assign" images... just to see if I can... Many thanks. ps: Does this mean I have to download your video again?
TBird: You mentioned the difficulty you had with the speed because of the "grid". I used the grid for RC mainly because RC does not seem to have sprite collision. "Detecting" a sprite, by placing it in an array, seemed to be more efficient than fiddling with some kind of 'pixel-perfect' system. I am not opposed to "non grid" games, I'm just lazy, in that regard... lol If you have any ideas for "non grid", as they say - and it's never said who "they" are - I'm all ears... lol
|
|
|
Post by n00b on Apr 1, 2019 15:42:29 GMT -6
johnno56 the DrawImage_Blit and DrawImage_Blit_Ex can do the same thing you could do with grab in sdlBasic. If you want the RC equivalent of grab then look at the CanvasClip() function. Here is an explanation of each: DrawImage_Blit( image, x, y, src_x, src_y, src_w, src_h ) ------------------------------------------------------------ image - the image slot x, y - where on the canvas to draw src_x, src_y, src_w, src_h - the area of the image you want to draw DrawImage_Blit_Ex( image, x, y, w, h, src_x, src_y, src_w, src_h ) ------------------------------------------------------------ image - the image slot x, y - where on the canvas to draw w, h - used to draw the image to your own scale src_x, src_y, src_w, src_h - the area of the image you want to draw CanvasClip ( image, src_x, src_y, src_w, src_h, flag ) -------------------------------------------------------------- image - the image slot to save the src area of the canvas in src_x, src_y, src_w, src_h - the area of the canvas to copy flag - unless you have a program with multiple windows just set this to 1
|
|
|
Post by tbird on Apr 1, 2019 21:08:08 GMT -6
I understand the motive behind it, collision detection in RC is entirely manual, your array system is quick n dirty, but functional.
Do not worry about changing it, it's your project, it being tricky to get it smoother was fun, I enjoy challenges! It is how we learn, do something different.
As long as its working for you, run with what you got going, quickly though, we need more levels haha!
|
|
|
Post by johnno56 on Apr 1, 2019 21:50:30 GMT -6
Tbird,
The reason for the enquiry into collision detection was not to change the game to a "non grid" system. I am trying to use only one image (spritesheet) to 'clip', 'grab, 'get' images, regardless of grid or non-grid, to see if its easier than performing multiple 'loadimages'. Until I can cobble together the appropriate code to perform such a task, I am still doing it 'old school' - load one image at a time...
I have found a tileset that could work. Instead of using two images for the 'framework', this new set has 16 tiles. Modifying the game to cater for the extra images is taking time, but hopefully, I should have something by days end or tomorrow. I will reproduce level one and if I can get if finished I will post a screenshot.... Fingers crossed...
|
|
|
Post by johnno56 on Apr 2, 2019 14:21:10 GMT -6
I'm going to change my mind a little. I tried using 16 framework tiles , which looked really nice by the way, but it made 'gravity' a bit cumbersome. Instead of detecting just two tiles (grass and ground), gravity - as well as left, right and jump - has an extra 14 tiles to collision check... I think I will stick with two, a background and a little music. Here is a current screenshot. I am in the process of modifying / creating levels. Eventually I would like to introduce hazards. Suggestions for improvements are always welcome.... ps: All graphics (except for blocky) are from OpenGameArt.org
|
|
|
Post by johnno56 on Apr 2, 2019 19:46:03 GMT -6
I have duplicated level 1 with the 'new' tiles and have thrown together a second and third level. I suppose I should have asked this before beginning. The method I am using, a grid system as tbird rightly said 'quick and dirty', is considered 'old school'. This is the only system I am familiar with. Can some throw a little illumination on 'other' systems? platform4.zip (856.86 KB)
|
|
|
Post by tbird on Apr 3, 2019 7:35:18 GMT -6
Actually johnno what I was getting at was the collision detection and movement, instead of using bounding box or circle collision it is all grid based, and the movement instead of pixel movement, again is entirely grid based.
To be clear there is absolutley nothing wrong with it. Your using tiles so you use an array too place them nothing odd there. The system you are using, nothing wrong with it, and it's very simple.
|
|
|
Post by n00b on Apr 3, 2019 8:07:52 GMT -6
I agree with TBird. There are a lot of older games that used grid based movement like zelda and final fantasy. I can't think of any platformers off the top of my head but it does seem to work for your game.
|
|