Messages

31

General / Re: Interesting SFML related find...

« on: April 15, 2016, 05:22:23 am »

https://github.com/OpenDungeons/OpenDungeons/search?utf8=%E2%9C%93&q=sfml

Apparently, it was included in that project since at least 2013.

32

SFML projects / Re: Ray Tracer

« on: April 15, 2016, 05:20:15 am »

It's the Utah teapot, it's pretty much the "hello world" of 3d.

33

SFML projects / Re: Slimey Carnage

« on: April 07, 2016, 07:25:38 pm »

Actually levels 7-1 through 7-6 are near duplicates of previous levels - slightly altered and a little harder. Namely, 7-1 is 1-10, 7-2 is 2-10, 7-3 is 3-10, 7-4 is 4-10, 7-5 is 5-10, 7-6 is 6-10. All other levels are unique.

Aww, and I thought that I was being perceptive catching that level 

However, I'd be interested in what you mean by "ghost jump"?

Ghost jump is allowing the player to jump even after they left a platform and started falling, usually just for a couple to several frames. It is used in the vast majority of platformers - at least good ones -, it vastly improves the feel of the game, and eliminates the latency issue where the player actually presses the jump button at the right time right at the edge of the platform, but because of latency, the jump press will register in time, and he will fall instead, or in the case of your game, cannot double jump after the air jump.

More elaborate articles:

http://www.gamasutra.com/blogs/MarkVenturelli/20140810/223001/Game_Feel_Tips_I_The_Ghost_Jump.php

http://www.gamasutra.com/blogs/AdamSaltsman/20100929/88155/Tuning_Canabalt.php

Thank you! I appreciate you typing all that out, and your honesty!

Glad it helped, I reach the end of a project sometimes, and nothing help me improve it more than a brutal but friendly other pair of eyes. 

34

SFML projects / Re: Slimey Carnage

« on: April 07, 2016, 10:43:09 am »

Great game  , flawed but great. Finished everything including world 7 and collecting all these yellow circles. Here some of the problems that I found in the game:

1- stage 6-10 and 7-6 are the same stage, they just have different exits. The exit is 7-6 is in the same place of the circle in 6-10, and you can't get to stage 7-6 without collecting the circle from 6-10 anyway, so the player is repeating the exact same thing.

2- Some hit boxes are questionable, but the rotating star hit box is just wrong, it's way too big compared to its sprite. the bomb explosion hit box stays way too long, much longer than you'd expect.

Also, the sides and the top of the screen kill you!? There should be something indicating that they are lethal, when there is nothing is on the side of a level, I assume by default either it is a wall or the screen will scroll.

The bottom should be lower than it is, there are many jumps that I plan to go off screen from the bottom before I jump again to a platform, but I can't because of the kill box. Same thing from the top.

3- Time wasters, these kill the pace of the game, main two offenders are insect traps, and spike traps. Spike trap takes long to go back, and takes too long to appear which looks pretty odd, traps usually snaps into position, and retracts slowly. This one activates slowly, stays in place too long, then retracts slowly, waiting for them is pretty tedious, but they are not even close to how bad the insect trap is.

Every thing about the insect trap is bad, it is the second worst thing in the game, they waste a lot of time, they are random, and twice in the game, they are in a combination with other traps, that appear to be impossible - or at least very difficult - to avoid death from first time, I had to activate it, die, then run fast to go past it before it activates again.

4- Absolute worst part about the game, the random yoyos. Nothing worse in a skill based games than doing everything spot on, just to be killed because you were "not lucky enough". If those f**kers were in the start of the game, I would not have touched the game with a light year long pole.

5- Jumping, a fixed height jump really gives a bad, outdated and clunky feel to the game I found my self  .Also, the game might benefit from a small ghost jump.

Still a fun game, the difficulty is perfect for me, and skill games should always be difficult IMHO, other ways they lose their whole appeal.

35

General / Re: Problem When a Window is Very Small

« on: February 23, 2016, 11:33:41 pm »

Yay 



It's a chip-8 emulator running a pong rom by the way, not a pong clone 

Thanks everyone for the help 

36

General / Re: Problem When a Window is Very Small

« on: February 16, 2016, 02:14:22 pm »

It's not SFML causing this restriction; it's the operating system.

Not exactly, as the code shows, I wanted a window with a framebuffer of 64 by 32 pixels, but the actual window size that I wanted is 600 by 300 which is bigger than the os minimum, but the problem still occurs. The limit should not be bound by the framebuffer size.

I'm not familiar with the inner working of sfml, but I'm guessing this could be solved by giving the option of specifying the window size - not just the framebuffer size - before the window is created, not just after. Sounds like an option that could be added to the window style class.

Again, not a big deal that is needed often. Heck, even I don't need it anymore.

37

General / Re: Problem When a Window is Very Small

« on: February 14, 2016, 09:08:17 pm »

I know, I know    I just wanted to make sure I wasn't missing an obvious fix. Actually now that I think about it, I'll need a bigger image anyway to display the text overlay later.

38

General / Re: Problem When a Window is Very Small

« on: February 14, 2016, 07:25:11 pm »

Yeah, I know, I might have not explained properly, the problem is that sfml does not resize the window to the min size, it actually forces the window to be 115 pixels wide - real framebuffer pixels, not just pixels added from resizing -, so other stuff - on the right side - gets rendered when they shouldn't, if it just scaled the window - as in resized -, it would have been fine in my case.

I solved my problem by just scaling the sprite horizontally until it filled the added gap since it's the only entity I need, and now it works even if it is stretched, but proportion is not a problem in my case. So I guess I'll just need to keep in mind in the future that sfml cannot render bordered windows that are less than 115 pixels wide.

Thanks for the help. 

39

General / Re: Problem When a Window is Very Small

« on: February 14, 2016, 11:27:26 am »

Thanks, that makes sense now 

Is there a way to have the window bigger than the min size, while still having a 64 pixels width? I don't care about the window size - actually I prefer it big -, but I do care about the pixel number, and I'd like to avoid making a single pixel 5 pixels wide.

40

General / Problem When a Window is Very Small

« on: February 13, 2016, 10:39:13 pm »

Hi, I'm using a 64 by 32 pixels window, and this happens :

64 by 32:


The magenta is the "window.clear" color, red is an sf::image with the same width and height as the window, so it should cover the whole window, but it doesn't. I though I was doing something wrong, until I decided to see what happens if I increase the window and image sizes, and it works then as intended - they are still equal - :

640 by 320:


The problem occurs when the width is 115 or less, not sure if it is an sfml bug, or if I'm missing something.  Here's the code:

#include <SFML/Graphics.hpp>
#include <SFML/Window.hpp>
#include <SFML/System.hpp>

int main()
{
        const int h = 32;
        const int w = 64;

        sf::RenderWindow window(sf::VideoMode(w, h), "Chip_8");
        sf::Image  image;
        image.create(w, h, sf::Color::Red);
        sf::Texture timage;
        timage.loadFromImage(image);
        sf::Sprite simage(timage);
        window.setSize( sf::Vector2u(600, 300));

        while (window.isOpen())
        {
                sf::Event event;
                while (window.pollEvent(event))
                {
                        if (event.type == sf::Event::Closed)
                                window.close();
                }

                window.clear(sf::Color::Magenta);
                timage.update(image);
                window.draw(simage);
                window.display();
        }


        return 0;
}

41

General discussions / Re: Simple Triangle Based 2D Collision Detection / Start of a tutorial series

« on: November 11, 2015, 07:17:28 am »

I don't understand why people keep re-implementing geometry algorithms again and again. Almost always worse than existing libraries with respect to performance, features and bugs, and even if it starts as "just for learning purposes", it ends up being used in production code.

Control and modifiability, I prefer taking a week to implement a feature I have full control and understanding over, than use an external library that could introduce a single bug that will destroy months of work, or needing a modification in a feature that I need, but I can't do much about that library's bugs and features without wasting a ton of time.

But that is true for simple features only, complicated features that would take months to implement is worth the risk of using a library.

This is just my personal tip to use your time more meaningfully. One day you won't have enough of it anymore, and then you'll regret having spent most of it reinventing wheels and not developing games

Words of wisdom, too bad it is already too late for me 

42

General discussions / Re: Simple Triangle Based 2D Collision Detection / Start of a tutorial series

« on: November 10, 2015, 10:43:40 am »

So these triangles are not intersected using this algorithm?



You can add line intersection detection to fix this. This method looks usable for simple geometry, but cutting complicated geometry to triangles will increase the detection time exponentially with each triangle.

Plus, tessellation could be more complicated than SAT - efficient and fast tessellation at least -, so you'd still need to wrap your head around something in the end 

43

General discussions / Re: Why do so many game take so much space?

« on: September 23, 2015, 06:01:17 pm »

Bigger games are usually 3d games, it is rare to see a 2d game get very large. 3d games are large for several reasons, but here are the big 2:

1- The 3d mesh nowadays can be VERY detailed, it is actually getting ridiculous, we are reaching "triangle smaller than the rendered pixel" kind of ridiculous, so you would need larger space to store them, not to mention that you will need multiple level of detail copies for each object, at least until tessellation become more popular.

2- Textures in 3d is much, much worse than the 2d ones for 2 reasons:

      a - In 3d you can get closer and farther away from objects, so the texture on them would need to be much bigger than the screen to not be pixelated, unlike 2d where you rarely need texture bigger than the screen other than the backgrounds, in 3d you need large textures every where.

      b - In 3d, textures are not used just for color - called diffuse map -, textures are also used for bump, normal, reflection, refraction, lighting, wet, specular, opacity... and many other types of maps, and almost every object uses multiple of these if not animated ones so the size can get bloated very very easily.

I sill will take mario 64 - 6MB - over most    all of these 30 GB games  . Games used to be fun, not fakely epic, and boring

44

General discussions / Re: I was looking at SFML Transform.cpp and Transformable.cpp

« on: September 22, 2015, 02:29:20 am »

You are basing your reasoning on it bieng 2d, and using the CPU, while SFML uses opengl which is in 3d only. How are you going to implement this in the GPU without requiring OpenCL, CUDA or the recent OpenGL compute shader?

45

General discussions / Re: SFML 3D logo

« on: August 22, 2015, 11:32:11 am »

It is not empty space, it is a white surface



I wanted to make sure it is as white as the logo without forcing it to be white. I thought i did't make a good job of that since you can still see that it is darker in the bottom than it is on the top. But your comment tells me that I kind of succeeded