FreeBasic Games Directory Forum
FreeBASIC Game Development => Work In Progress => Topic started by: Lachie Dazdarian on December 26, 2007, 10:17:04 PM
-
This is something I've been working on during past few days. It was developing slower than I expected.
(http://lachie.phatcode.net/scrn_by_scrn_engine1.gif)
(http://lachie.phatcode.net/scrn_by_scrn_engine2.gif)
(http://lachie.phatcode.net/scrn_by_scrn_mapeditor.gif)
Download: http://lachie.phatcode.net/scrn_by_scrn_engine_v042.zip (updated on 10.02.2008)
Check readme for new planned features.
Yeah, code cleaneup is something I forgot to mention there too.
P.S.
I'm not making a GOD DAMN game!
-
Why are you not making a game?
The character moves much faster in the scenebyscene exe than in the scenebyscene_small. I havent looked in the code but is that on purpouse?
There is also a little problem with portal number3. If you are quick on the keys you can move your character outside the house.
Still, it looks like an interesting engine. What are you going to do with it if you are not making a game?
-
Not bad at all, except that the tiles are pretty bad :P
The character does run around a lot faster than I'd expect; I don't mind, since in a demo I don't like going slowly anyways, but you might want some sort of fps limiter or something. And yeah, Portal 3 is impossible to get into unless you do some weird thing running around really fast into the portal.
One thing that would be really nice is if you get pp collision implemented. Foreground layers would also help, so you can walk under the trees, but I see that's already on your list.
-
Ahahah this reminds me of QB :P
-
There is also a little problem with portal number3. If you are quick on the keys you can move your character outside the house.
Still, it looks like an interesting engine. What are you going to do with it if you are not making a game?
Thanks for reporting this bug. There seems to be a problem with coherence of map edge collision and tile collision. Actually, I think it's one pixel of space in tile collision that allows you to do this. Will fix that.
I will most likely make a game in it eventually. But I want to complete this engine properly so that making a game in it doesn’t end up being a nightmare. And I don't want for my future possible game to be judged on the engine placeholder graphics.
Not bad at all, except that the tiles are pretty bad :P
The character does run around a lot faster than I'd expect; I don't mind, since in a demo I don't like going slowly anyways, but you might want some sort of fps limiter or something. And yeah, Portal 3 is impossible to get into unless you do some weird thing running around really fast into the portal.
I did these graphics in about 1 and a half, and I think it's pretty good having that in mind. No offense, but majority of FB programmers can't handle something like that. At least I didn't resort to using non-original tiles. It's all my original work. RESPEKT!
The difference in running speed is the result of one character moving in environment consisted of 20*20 pixel tiles, and the other in environment consisted of 40*40 pixel tiles. I kinda tried to adjust the speeds, but was too lazy to do it properly.
It is not near impossible to enter portal 3. I just made the tile collision box too big so you need to be very...hmm...precise. Just kiss one side of the castle wall and more toward the door (hold up and right or left). That should do the trick.
I guess I will have to finishing this properly in a higher resolution, with spiced up graphics, for it to stop reminding people on QB.
Oh yeah, PP collision is considered, but then colliding objects will have to be in a separate layer, pasted with TRANS.
Got a lot of work to do. *sigh*
-
I guess I will have to finishing this properly in a higher resolution, with spiced up graphics, for it to stop reminding people on QB.
Hey, reminding people of qb isn't all bad. I like low-res.
-
Well I guess it's better to use your own tiles than resort to a pre-made set like you said. Probably the worst one is the grass. If you made it look better, the rest wouldn't be terribly bad. Don't worry about it too much - especially if you aren't making a game anyways!
But umm... like he said. Why make an engine if you aren't making a game?
-
Ok, I'm posting a new version of my engine.
Changes? Foreground layer fully implemented, added tiles file browser in the map editor, save game script option, save Y/N messages, and the implemented screen resolutions have been changed (now they are 320*240 and 640*480)..
Both codes cleaned up.
Things to do: Finish map editor interface, change map files format (make a single map for the entire location), add pixel perfect collision object layer.
-
Err... in the library the trees outside have pink in them (the transparency is wrong, since when you darkened them you darkened the pink as well so it's not &hFF00FF any more).
Other than that, not bad. Pixel perfect collision is a must, I'm looking forward to it. Right now you still can't walk very close to the base of the tree, and you can't walk "behind" the fences at all.
-
Meh, pixelperfect collision is overkill. Just add some different collisionboxes to make it look better.
I noticed when walking out on the left from the castlemap that I ended up on a map that wasn't connected with the castlemap at all but that is just details.
-
It's an error in game1_script.txt that I omitted. 640*480 example doesn't have this bug. I left the location exit definitions in the first script by mistake, and as I said previously, this feature (world/location exits) didn't turn out to function as I expected it would. I might leave it out in the next version.
I will try to implement an colliding objects layer, and since it will be a layer users will have an option to use it or not.
-
Meh, pixelperfect collision is overkill. Just add some different collisionboxes to make it look better.
You may be right, I never thought of that. Perhaps I should experiment with that in my own code...
-
Yeah, seriously (whatever spelling you feel comfortable with, im drunk). You can come along way without pxp colllision.
-
Nice start! Good to see more rpg projects(or maybe it wont be an rpg?)
Some things I've noticed:
- the character is in a terrible hurry..
- maybe his walk animation should stop when his colliding with objects?
- the graphics are a bit bright for my taste
Also the pink tree's when your inside the castle.
Anything in a lower resolution then 640x480 can remind people about qbasic so thats not a bad thing =) I see you have dropped the old palette and started to use 24bit colors, thats what I've done to. Haven't missed the palette yet :D
-
By the way, you can make your character's speed based on the fps. I don't bother with fps limiting, I just do it this way:
charSpeedX = speedConst/fps
charSpeedY = speedConst/fps
where speedConst is some value you'll have to experiment with to get the speed just right.
It's easy to do and it will make your character keep a consistent speed no matter the fps (you can experiment for example in different resolutions and you'll see that as the fps changes, the speed doesn't seem to.
-
New version 0.3 is available (check the first post for download)!
Changes/additions:
* pixel perfect collision layer fully implemented
* foreground layer fixed (related to being behind or in front of objects in that layer)
* added a necessary overlay layer for object always drawn in front of the player
* stuff
Anyway, for all this to give a desired effect you need to draw the appropriate sprites and place them in the appropriate layers. Anyway, I think the example maps illustrate this quite well.
All that is left to be done is a layer with objects that you can slide off, and improved map editor.
Edit: Small update. Version 0.3.2. Pixel perfect collision improved and few fence tiles corrected.
-
Very Nice;
it looks good; now too bad your not making a game; some of your graphics would work for a good game, others didn't catch my good side, if you know what i mean
-
hum... c00l, interesting idea...
but you need especific tiles to use in the collision layer, i dunno if this is good or not =] altough it makes the collisions probabily a bit more realistic
-
Well, I have no idea how to solve this otherwise. I mean, how to mark specific pixels for each foreground sprite that are colliding? A colliding layer is a much simpler solution.
-
If you have a separate image attached to your sprite (specified in a config file, probably) that is the same thing but only has the feet in the picture, then you base collisions on the CollisionSprite while drawing the DrawingSprite.
Another solution is simply bounding box at the feet. Basically, you want to check the feet. And of course Pritchard's 2.5D tutorial uses a bounding box in pseudo-3d.
-
Hrm...I don't think you thought about this in details...or checked the code of the latest version.
I'm already using walk sprites (basically, it's the bottom third of my main sprite) for collision with the collision layer. And collision layer objects also need to feature parts of objects in the foreground layer that are meant to be colliding, them too representing the bottom of those objects (like with the fence). As I already said (not sure if here), foreground layer represents those objects that are in level with the player (the player can be in front and behind them) and they are pasted over the base layer.
For the player to be able to appear behind and in front of them I need to loop through the foreground objects twice, once before the player pasting and once after. I don't how this can be solved without some sorting, but it's pretty much the same.
In the currently scheme it's - check for foreground sprites above the player and paste them, paste the player, check for foreground sprites below the player and paste them. With sorting it would prolly be, sort foreground sprites according to player's position, paste the first group, paste the player, paste the second group of sorted foreground sprites. The second doesn't sound better.
The only way to avoid collision layer definition I can think of is foreground tiles pointing to colliding tiles in the tileset, so I wouldn't have to manually define the collision layer. This, on the other hand, would mean forcing a certain tile arrangement format to the user (like the appropriate collision sprite following the foreground sprite in the tileset).
-
Yeah, you're probably right...
-
By the way, you can make your character's speed based on the fps. I don't bother with fps limiting, I just do it this way:
charSpeedX = speedConst/fps
charSpeedY = speedConst/fps
where speedConst is some value you'll have to experiment with to get the speed just right.
It's easy to do and it will make your character keep a consistent speed no matter the fps (you can experiment for example in different resolutions and you'll see that as the fps changes, the speed doesn't seem to.
That's highly dependent on accurate FPS calculations (which aren't always perfect). A much better way to do it is to track the time elapsed since the last frame, and then define all your speeds in units/second.
'In the beginning of the program
dim shared as double elapsed, lasttime
lasttime = timer
'Somewhere else in the setup (or loaded from config, or whatever)
dim shared as integer charspeed = 128 'pixels/sec
'main loop
do
elapsed = timer - lasttime
lasttime = timer
'Rest of main loop code
if (keys.left) then
char.x -= charspeed*elapsed
end if
if (keys.right) then
char.x += charspeed*elasped
end if
'etc
flip
loop
This way you can also use multiple frames to compute the FPS (and a very momentary CPU slowdown won't send your character shooting off at .999c for a whole second). It's also easy to do variable speed this way.
-
Yeah, time-based movement is something I need to implement, but I keep postponing that as there is always some other features to implement.
Anyway, I just realized that if I implement NPCs, I need a quite different scheme for the foreground layer drawing.
The best I could think of for now is:
First draw the ENTIRE foreground layer over the base. Sort the NPC according to their Y position (so they wouldn’t overlap each other inappropriately). Draw those above the player, draw the player, and then draw those below the player. The second time the foreground layer is drawn I would check for those foreground tiles around the player and NPCs (right, a nested FOR loop, ack!) and redraw foreground tiles "in front" of them if necessary.
Luckily, as this is a screen by screen scrolling engine and there shouldn't be really too many NPCs on one screen (20 tops), this shouldn't be too slow.
Uh-oh, another thing to play with the next weekend.
-
First draw the ENTIRE foreground layer over the base. Sort the NPC according to their Y position (so they wouldn’t overlap each other inappropriately).
Inappropriate NPC overlap! This sounds very interesting!
-
Hey! Don't mock my English!
Well, maybe I deserved it. :P
I have no idea why I didn't use the word «incorrectly». Bah.
-
By the way, you can make your character's speed based on the fps. I don't bother with fps limiting, I just do it this way:
charSpeedX = speedConst/fps
charSpeedY = speedConst/fps
where speedConst is some value you'll have to experiment with to get the speed just right.
It's easy to do and it will make your character keep a consistent speed no matter the fps (you can experiment for example in different resolutions and you'll see that as the fps changes, the speed doesn't seem to.
That's highly dependent on accurate FPS calculations (which aren't always perfect). A much better way to do it is to track the time elapsed since the last frame, and then define all your speeds in units/second.
'In the beginning of the program
dim shared as double elapsed, lasttime
lasttime = timer
'Somewhere else in the setup (or loaded from config, or whatever)
dim shared as integer charspeed = 128 'pixels/sec
'main loop
do
elapsed = timer - lasttime
lasttime = timer
'Rest of main loop code
if (keys.left) then
char.x -= charspeed*elapsed
end if
if (keys.right) then
char.x += charspeed*elasped
end if
'etc
flip
loop
This way you can also use multiple frames to compute the FPS (and a very momentary CPU slowdown won't send your character shooting off at .999c for a whole second). It's also easy to do variable speed this way.
Yes, that is much better, especially since it doesn't require division like mine does :P
-
Ok, a new version.
I implemented NPCs (they are on the third screen to the right) and a very smart method to sort the foreground objects, the player and NPCs so they would cover each other correctly according to their Y positions.
Nothing new beside that, but that thing was a big step and I quite like the new code.
I plan now to create an infrastructure for implementing/managing NPCs.
-
nice improvement; it's good that you corrected that, I'd hate to dig into code just to fix that...I'd hate to dig into code to fix anything! lol.
keep up the good work, looking forward to see any screen shots.
-
Nice work, Lachie. Some collision softening might be in order, but otherwise a very solid piece of work.
My only suggestion would be to implement early Zelda-type scrolling between areas. That would give a real classy feel to it.
-
Ahh....Most impressive. Very good work. It's very smooth and fast on my PC (P4 3.0/1Gb/XPP).
NOW GET BACK TO WORK ON BARREN! ;D
-Vince
-
Thanks. Well, it should run smooth on really old PC so...
Anyway, I did work on Barren a little last weekend. Erm...did you read my PM and the email that warned you about it?
I never got your feedback on that image.
-
Yes I did see it and it's looking good. I have been in a crisis mode for my work these last two weeks and expect it to last 2-3 more days before I get things in order. I have been re-working the junk scene. I should have that fininshed soon.
-Vince
-
NP. I just like to....you know....stay in contact regarding the project.
Anyway, I updated the engine. It softened the colliding objects and made the characters' colliding legs only to be a black rectangle (not drawn). Making characters’ real legs sprites as the collision objects was overkill. Much smoother now, although don't expect when you crawl into a tree root for the program to slide you backwards if you move left and right. That’s not even realistic, if we are going to venture into the topic of realism.