I posted the Arduino serial communication tool I am working to my GitHub [URL="https://github.com/harddal/ArduinoSerial"]here[/URL] if anyone wants to use it. It shouldn't be too buggy and I plan to add more features.
I also have the C++ port of cartman300's textbuffer for SFML that I said I would do. It is on my GitHub as well (with full credit to cartman300).
[QUOTE=Eric95;48754447]the wall texture is blurry as hell
and so are some of the UI elements, and the font rendering doesn't look very good either
gotta make shit crisp as fuck dude
besides that the game just isn't very visually appealing. it looks unfinished, and you don't have any kind of nice color scheme going. Having the camera clip outside the level into the skybox itself looks really, really unprofessional, and I have no idea why you'd put that in the screenshots on the page.
And the logo just looks like a smiley from one of those old virusy smiley packs that you used to see ads for on newgrounds in 2006. It doesn't look appealing or interesting, it looks more like something I'd scroll past because it looks like a quick cash-grab
basically i'm sure the game is fine but it needs a visual overhaul led by somebody with a good sense of aesthetics. an art director, perhaps[/QUOTE]
All textures are 512, I wanted to preserve file size. At 1024 it looks crispier but then file-size skyrockets. It bothered me too a bit but it's better to have smaller game.
Can I ask, what resolution you have? Because UI looks fine to me. About font, what is wrong with each font? Is the orange one that sucks or white one?
Thanks, might change some stuff.
[QUOTE=No_0ne;48756297][img]http://i.imgur.com/ipjgPVX.gif[/img]
been working on the player, i've added some simple idle animations when left still
[img]http://i.imgur.com/rGePksp.gif[/img]
i've also added a charge attack, which does more damage the longer you charge, still need to make special effects for it though
that white flash while charging took me like two hours trying to learn opengl shaders[/QUOTE]
Your gifs are always fun and cute.
[QUOTE=No_0ne;48756297]
[img]http://i.imgur.com/rGePksp.gif[/img]
i've also added a charge attack, which does more damage the longer you charge, still need to make special effects for it though
that white flash while charging took me like two hours trying to learn opengl shaders[/QUOTE]
My first thought was that he was being damaged when you were charging the attack. I love that idle animation though :D
[QUOTE=Rocket;48755474]Well, they said "skills, races, and whatnot," which I'm assuming is on the order of hundreds of kilobytes or a few megabytes. Not any size that matters.[/QUOTE]
[quote]and all the rest[/quote]
It's just text yeah. I was thinking it wouldn't be that big of an issue, but just wanted to be sure.
And they? I'm not a hivemine (yet!)
[QUOTE=DarkCarnage;48757641]I also have the C++ port of cartman300's textbuffer for SFML that I said I would do. It is on my GitHub as well (with full credit to cartman300).[/QUOTE]
My [URL="https://github.com/cartman300/SFMLTextBuffer/blob/master/LICENSE"]license[/URL] is the Unlicense. You don't have to give so many credits. :rolleyes:
[editline]25th September 2015[/editline]
In fact, all my code is. There's an exception or two though.
[QUOTE=Fourier;48757650]All textures are 512, I wanted to preserve file size. At 1024 it looks crispier but then file-size skyrockets. It bothered me too a bit but it's better to have smaller game.
Can I ask, what resolution you have? Because UI looks fine to me. About font, what is wrong with each font? Is the orange one that sucks or white one?
Thanks, might change some stuff.[/QUOTE]
The worst texture is really just the brick texture, bumping that up to 1024 would really make a huge difference. You don't have to change the other textures
I'm just looking at the screenshots, and it looks bad in the screenshot resolution. All of the fonts are slightly blurry and the UI too. Worst one is the hand marker in the tutorial picture though.
Also, why are you keeping the framerate displayed by default in the final version of the game? That feels much more like a dev thing, and it makes the game feel way less polished.
[QUOTE=Eric95;48758629]The worst texture is really just the brick texture, bumping that up to 1024 would really make a huge difference. You don't have to change the other textures
I'm just looking at the screenshots, and it looks bad in the screenshot resolution. All of the fonts are slightly blurry and the UI too. Worst one is the hand marker in the tutorial picture though.
Also, why are you keeping the framerate displayed by default in the final version of the game? That feels much more like a dev thing, and it makes the game feel way less polished.[/QUOTE]
Holy shit, I forgot to turn it off (FPS). I got so much used to it that I forgot about it.
I bumped up texture to 1024 and enabled "pixel perfect" for UI. It does make a bit of difference :).
I published new version, should be available in few hours.
J[QUOTE=Fourier;48758749]Holy shit, I forgot to turn it off (FPS). I got so much used to it that I forgot about it.
I bumped up texture to 1024 and enabled "pixel perfect" for UI. It does make a bit of difference :).
I published new version, should be available in few hours.[/QUOTE]
You should also update the screenshots then
[QUOTE=Arxae;48758335]And they? I'm not a hivemine (yet!)[/QUOTE]
They is more and more frequently used as a gender neutral pronoun.
[editline]25th September 2015[/editline]
Fourier, you should really get someone to write or proof-read the text in your game and on the store page for you. No offence meant, but there are grammar errors everywhere.
[QUOTE=Asgard;48758772]J
You should also update the screenshots then[/QUOTE]
Will do, it's just that game/build is more important.
[QUOTE=Tamschi;48757392]Since this seems more controversial than I though, I'll go into (a little) more detail regarding where the methods differ for the end user:
- framerate dips:
The most noticeable issue are when the device a game runs on can (temporarily) not keep up with the target framerate.
fixed time step: The game slows down, messing up the timing of player actions.
dynamic time step: Some visual detail is lost, but the flow continues unhindered to a point. (A time step should be capped to something like 1/10th of a second so hangs can't cause glitches or lock the player into an input state [I]if[/I] they happen.)
- minimal system requirements:
If the system consistently can only provide a framerate below the one the game is developed for, it can degrade the experience.
fixed time step: Requires some additional configuration and can't use all available resources without time slowing down or speeding up. (worst case: the game can run consistently slower if programmed badly)
dynamic time step: The game will run at the intended speed and use the available resources to reach the highest framerate possible at any time.
- more powerful systems:
fixed time step: The game can't easily be rendered 1.5 times as often, especially when 1 frame = 1 update. If updates happen more often there's still granularity that causes stutters with v-sync without an exact framerate match. It's possible for the player to configure it manually or to somewhat reliably detect any necessary options, if most of the code would work with a dynamic time step.
dynamic time step: If a computer can render a game 1.5 times as often as normally that's fully automatic.
There are a few exceptions of course. In fighting games you can't use a dynamic timestep because the accuracy of user input and animations are extremely important. These games are usually balanced around that aspect.
If your game is traditionally animated, then the art provides a framerate that can't be deviated from because no correct output exists for the time in-between.
However, in those cases you can simply take a dynamically timed framework and input a constant time step centrally, which will then lead to correct results there with the characteristics of a normal fixed time step program.
In any case you need to cap your game so it doesn't run faster than the results can be displayed on screen, or you'll waste a lot of electricity.
This too is easier with a dynamic system since for example Windows seems to reduce the refresh rate of windows that aren't in focus which can happen at any time.
(If the game is completely hidden/minimised you can detect that through window messages and enter power saving mode. You can do the same if you temporarily lose your graphics context (which [I]can[/I] happen e.g. if the driver crashes).)
If your game algorithm is stable enough you could go down to one update every ten seconds while the user isn't looking at it.
A player may also prefer a lower fixed framerate over one that's possibly not constant, which they can still easily choose with good efficiency if the timestep is internally dynamic.
The one instance where it's reasonable to use a fixed timestep for performance is if you have a lot of complex animation but no blending (which is common in Japanese games locked to 30fps I think).
In that case you can cache and/or load all final animation frames from disk and play them back with very little processing. However, this for the most part only applies to 3D (since 2D animation is [I]much[/I] cheaper) and even then somewhat modern computers should easily handle a good amount of characters (especially considering you can thread this without much difficulty).
A "fixed timestep program" is a little bit less work to type out too (due to shorter formulas when done improperly), but hopefully that's not relevant for anyone here.
As an aside: The possibly most egregious example of fixed timestep I've seen so far is in [I]Alice: Madness Returns[/I].
Certain parts of the game engine assume [I]~5fps with no interpolation[/I] and will always stutter due to that. The most noticeable is probably the cursor in rhythm minigames, but most menus also seem to suffer from (something) like this.[/QUOTE]
How do you deal with making things like physics deterministic when using a dynamic time step? The physics systems I have used (which isn't many, to be fair) have all used a fixed timestep to operate correctly.
It seems to me that the best solution would be a mix of the two; dynamic timestep for rendering and fixed for everything else.
Usually when I write games, I have two separate update loops running. One running on a fixed timestep for doing game logic updates - physics, AI, pathfinding, and the like. Another one running on a dynamic timestep doing visual updates - animations, position interpolation, blending, tweening, etc.
With that, you can get the best of both worlds, as well as a good entry point for doing multi-threading.
Hardest part is properly syncing between physics and visual bodies. If you make that right, you should get butter (which was in microwave) smooth performance.
The mix of dynamic and fixed timesteps is also what Unity Engine uses.
You have FixedUpdate() running on a fixed timestep and Update() running per frame.
[QUOTE=krix;48758986]The mix of dynamic and fixed timesteps is also what Unity Engine uses.
You have FixedUpdate() running on a fixed timestep and Update() running per frame.[/QUOTE]
And that works great imo
Added a zombie surfing mini-game to my zombie game.
[video=youtube;Fnj8A9fqVWA]http://www.youtube.com/watch?v=Fnj8A9fqVWA[/video]
[QUOTE=Asgard;48759166]And that works great imo[/QUOTE]
It would be cool if you could say this.rate = 5, and FixedUpdate would run every 5 fixed frames :).
this.rate default would be 1 of course.
[editline]25th September 2015[/editline]
[QUOTE=Torrunt;48759532]Added a zombie surfing mini-game to my zombie game.
[video=youtube;Fnj8A9fqVWA]http://www.youtube.com/watch?v=Fnj8A9fqVWA[/video][/QUOTE]
That is actually quite awesome!
[QUOTE=Fourier;48759562]It would be cool if you could say this.rate = 5, and FixedUpdate would run every 5 fixed frames :).
this.rate default would be 1 of course.
[/QUOTE]
[T]http://docs.unity3d.com/uploads/Main/TimeSet.png[/T]
i'm curious
what happens with fixed timestep if the function takes longer than the timestep?
[QUOTE=DarKSunrise;48759773]i'm curious
what happens with fixed timestep if the function takes longer than the timestep?[/QUOTE]
I assume it just tries to call it as soon as possible then
[QUOTE=DarKSunrise;48759773]i'm curious
what happens with fixed timestep if the function takes longer than the timestep?[/QUOTE]
There's a maximum allowed timestep, it won't go past that amount.
[editline]25th September 2015[/editline]
So it effectively links your framerate and gamespeed together if you go below the maximum allowed timestep
[QUOTE=Torrunt;48759532]Added a zombie surfing mini-game to my zombie game.
<video>[/QUOTE]
That looks really cool, will there be chance to play this at some point?
[QUOTE=Syntox;48759992]That looks really cool, will there be chance to play this at some point?[/QUOTE]
Yeah, I want to release it eventually, get it on Steam and that. I wanted to get it out this year, though it's just me working on it and I procrastinate a lot so I don't know if that will happen. Maybe if I manage to get it to a decent point I could try releasing it in Early Access.
[QUOTE=BackwardSpy;48758858]How do you deal with making things like physics deterministic when using a dynamic time step? The physics systems I have used (which isn't many, to be fair) have all used a fixed timestep to operate correctly.
It seems to me that the best solution would be a mix of the two; dynamic timestep for rendering and fixed for everything else.[/QUOTE]
As far as I am aware there is no common physics engine that actually guarantees determinism, so if you're relying on that you may well only get it out of luck. However I think what you're talking about is the stability in simulation you get from stepping a consistent or identical amount of time. In which case you basically just have to do that.
Also I just wanna talk about frames a bit because it annoys me every time it comes up. There is no single best way to do it. If you do the super naive thing of simulating the time it took the last frame to simulate, you are always showing the next frame at the wrong time for what was simulated. Each frame corrects the last frames error, which is why this can appear to work, but it's wrong. There are potentially many games which unintentionally use vsync to stabilise the frame times. If you separate the two like in that gafferongames article, then you introduce a frame of latency, complicate your code and you can potentially get further latency from the desychronization of rendered frames to real updates, or stutters when you need to do more updates per frame, depending on how much you multithread it.
The lowest latency and most "correct" way to do it, is to update at multiples of your desired frame rate for that exact amount of time, and render frames for that frame rate. This assumes that you can simulate, render a frame and get it out within that frame or it will fall apart of course, so it may not be appropriate at all depending on the game. I would say that computationally simple games should definitely be doing this.
So in my opinion it's really not as black and white as "use a dynamic timestep".
Anyone here can recommend some cheapish dedicated server providers?
[QUOTE=Map in a box;48760704]Anyone here can recommend some cheapish dedicated server providers?[/QUOTE]
DigitalOcean (if a VPS is what you're after).
[QUOTE=Map in a box;48760704]Anyone here can recommend some cheapish dedicated server providers?[/QUOTE]
Check out [URL="https://www.scaleway.com/"]Scaleway[/URL]
[QUOTE=SteveUK;48760786]DigitalOcean (if a VPS is what you're after).[/QUOTE]
Dedis, not VPS. And DO is rather overpriced for the specs.
Currently eyeing soyoustart
Sorry, you need to Log In to post a reply to this thread.
