Comment below on what you think of the physics.
Z to jump.
X to shoot an arrow.
Comment below on what you think of the physics. Z to jump. X to shoot an arrow. | |
Sep 19 2011, 5:39 pm
|
|
Kaiochao
  |
Double-jumping lets me fly? Cool!
|
Fixed that bug, thanks Kaiochao. (:
| |
Bug spotted... Jump over through the ladder... but make sure you land on the floor above it. I am doing it on the very first ladder. You won't be able to jump unless you go on a ladder again.
EDIT: lololol... I can fly also.. if I jump on the ladder and hold z. | |
There's something wrong with your gravity. Mashing the jump button gets me stuck to the ground or flying through the air.
You might want to increase the framerate, Fraps was reporting it to be 15fps when in motion. Also, it seems your map is 1x1 bigger than it needs to be, you should cut that out then adjust the client.pixel_x/y by 16. The map isn't anchored correctly. Maximizing the game window lets me see out of bounds. | |
@Akto: Yeah, that bug was found, I'll fix on it later today.
@SuperAntx: The double-jumping is fixed. I need to fix the ground sticking later today. The framerate is increased. The map is supposed to be that size. The window won't be directly resize-able in the future. The only reason I make it resize-able now is so I could test the teleporters. | |
My laptop isn't a powerhouse but this demo runs terribly slow for me. It runs better when I go into the other room, but the first screen is very slow. Are there that many more objects on the first screen?
The second screen only wraps one way. If I walk off the left side I appear on the right side, but it doesn't work the other way. I'm not sure if this was intentional. Arrows don't wrap around, but I'm guessing that was intentional. I also noticed some problems with gravity, but it's hard to tell on here what part of the problem is the low framerate and what part is the game's logic. The sidescroller library doesn't have any of these bugs. If it ever did, it's had more people spending more time on testing and bug fixing. It might feel rewarding to say you made it yourself, but it looks like you're just spending time fixing bugs you shouldn't have to bother with. | |
Oasiscircle wrote:
The map is supposed to be that size. Right, but you're needlessly rendering extra tiles, leading to reduced performance. You should be making cuts wherever you can. Tiles being rendered outside of view is definitely a bad thing and should be taken care of. | |
@SuperAntx: I fixed the map's x problem, I was just doing that for some screen-wrapping bug testing.
@Forum_Account: I did figure out what was making it lag, it was the way I was checking for the ground. (I was using !step() too much.) It should run better with the up/down scrolling. About the completely open room, the scrolling doesn't work because I didn't expect anyone to go into those rooms. I don't have the screen-wrappers set up in there on one side. Gravity and inertia should be working as I want it now. You have offered many many times your side-scrolling library. I would appreciate it if you would stop trying to push your library on to me. I know your intentions are good, but you are very persistent and it's getting to the point of annoyance, so I'd really appreciate it if you would just stop. | |
PS: Not a fan of the name Majeure, it's french for Major, and makes it sound weird. Kind of like when people write rogue as rouge, rouge is french for red.
| |
Force majeure (French) - By act of a god. Ties in with the storyline.
| |
Oasiscircle wrote:
@Forum_Account: I did figure out what was making it lag, it was the way I was checking for the ground. (I was using !step() too much.) It should run better with the up/down scrolling. That makes sense, but it's weird that it was slow on one screen but much smoother on the other. I didn't get a chance to try this on my desktop, but I'm guessing it's just because my laptop is slow and the first screen had more objects. You have offered many many times your side-scrolling library. I would appreciate it if you would stop trying to push your library on to me. I know your intentions are good, but you are very persistent and it's getting to the point of annoyance, so I'd really appreciate it if you would just stop. What are your reasons for not using the library? You seem determined to not use it, but if it's a personal issue there may be someone with similar apprehensions that can still be swayed. If it's an issue with the library, it can be changed - the library would be terrible if it weren't for user feedback. The reason I persist is because it's frustrating to see people refuse to use the library, waste weeks posting about progress that could have been accomplished in much less time, inevitably lose motivation, give up on the project, and in the end nobody has anything to show for it. The project is sitting on a shelf where nobody can play it and no developers can make use of its code. To be direct, if Majeure isn't going to go the way of Delve and Rocket Down, something needs to change. I get the impression that the code in your projects gets too unwieldy too fast. If every feature you add complicates the rest of the code just a little bit, eventually you'll reach a point where the mess is too much and progress stalls. Developing features as demos for the Sidescroller library is a good way to get a simple, stable implementation of a single feature that can easily be included in a larger project without making things messy (sharing features with others and getting extra sets of eyes testing your code is a bonus). Making mobs wrap around the left and right sides of the map took 12 lines of code and it automatically plays nicely with all other features. It's not a special case that complicates everything else. | |
Forum_account wrote:
What are your reasons for not using the library? You seem determined to not use it, but if it's a personal issue there may be someone with similar apprehensions that can still be swayed. I've told you numerous times it's way too dense and confusing. The keyboard stuff for instance has nothing to do with pixel movement yet it's in your lib. BYOND's pixel movement is so much simpler in comparison. | |
SuperAntx wrote:
I've told you numerous times it's way too dense and confusing. The keyboard stuff for instance has nothing to do with pixel movement yet it's in your lib. BYOND's pixel movement is so much simpler in comparison. I'm not sure what "too dense" means. BYOND's default keyboard handling just isn't sufficient. Sometimes you need to know if a player is holding down a key (ex: to determine if they fall through a platform), so you need to remember the state of each key. I agree that this isn't exactly related to movement, but the library needs to handle this because BYOND doesn't handle it. BYOND's pixel movement is simpler, but much less functional when it comes to game development. The library has always done these two things: 1. Provide pixel movement. 2. Provide the interface to the pixel movement feature. BYOND only gives you #1, it doesn't give you a useful interface to the feature. There's not even a built in way to say "move this mob by this many pixels in the x direction and that many pixels in the y direction". It's not a problem that the library does this for you, it's a benefit. | |
Sorry F_A, it is basically a personal "problem", I like to know where everything is in my code. Otherwise I spend too much time trying to figure out where each part of everything is.
I've got nothing against using libraries, I reserve libraries for things that I would never be able to do on my own because of lack of knowledge, like doing dm2MySQL, just as an example. | |
I'm glad I'm not the only one tired of F_A pushing his lib... Apparently every person and his dog who mentions pixel movement should use F_A's lib.
PS: Force Majeure is a term, Majeur is just a word. I'll stop mentioning it, but I won't like it. | |
Oasiscircle wrote:
Sorry F_A, it is basically a personal "problem", I like to know where everything is in my code. Otherwise I spend too much time trying to figure out where each part of everything is. I wouldn't put "problem" in quotes there because that is quite a problem. It's common but I still don't understand it. People want to understand how things work, but they're perfectly happy to use BYOND. When you put "var/a = 5", you don't know what happens because this is internal to BYOND. People tolerate BYOND's mysterious internals, but absolutely need to know how their DM code works. Not only is this behavior strange, it's detrimental. You should focus on knowing what things do, not how they do it. For example, in my project I have a knockback proc for each mob. When you call a.knockback(b), b is pushed away from a. The proc should be implemented in such a way that I only need to remember what it does, not how it does it. Needing to be aware of the details of how a proc works is a bad thing. Because the details don't matter, I can forget how it works and safely call knockback() whenever I need to. The reason people tolerate BYOND's mysterious internals is because BYOND is, for the most part, designed properly. You don't need to know how step() works because it doesn't have messy side-effects that complicate your project. You only need to remember what it does. If you need to be aware of the details of how procs within your project work, that means you have ugly side-effects that are gradually turning your project into a mess. This is would explain both the lack of finished projects (from BYOND as a whole) and the resistance to using the library: people don't realize this is a problem, they think it's necessary. A good programmer isn't one who is better at remembering the details of how code works, it's the one who writes code in such a way that you don't need to remember the details. | |