Messages

1

SFML projects / cpGUI - Anyone interested in developing?

« on: November 22, 2010, 05:35:09 am »

pdusen seems to have covered most of everything in regards to the previous discussion. I believe that there is more in the design that nfries88 has not seen yet but I don't have time to enumerate everything. I will respond to the design issues that nfries88 brought up when I have more time. I spent a lot of time designing (thinking about) the skeleton of the new API and talked w/ pdusen over email. I can send a copy if anyone wants to read in on what we discussed (and with pdusen's approval). We've yet come up with a public-disclosure style of communication (rather than private e-mail).

I also wanted to add that, in reference to my repository being more up to date than pdusen's (which is technically the master repo), basically I'm "coding" this thing while pdusen is sort of my "senior advisor" (who has actual experience in the field and such). He setup the build system and taught me how to use Git (among other things). Just in case anyone was wondering what's going on with that.

Also wanted to give an update from my end. I became less interested in the project after completing the framework/skeleton. The widgets are sort of trivial IMHO. Everything else should be able to just plug into the new API with minimal changes (to the API).

I'm primarily concerned about the design/API of the project. If I have time I will finish developing the widgets. I'm in college, CS major, senior year and don't think I'll be able to contribute much more but I do want to watch over the design of the project as it progresses (e.g. to make sure any contributed widgets work properly when integrated into the system). I'll post a more detailed response about the issues that nfries88 brought up when I have time. I didn't notice any issues concerning the way the GUI actually works so any API changes in regards to the issues brought up should be minimal.

2

SFML projects / cpGUI - Anyone interested in developing?

« on: October 28, 2010, 02:50:00 am »

1) You use namespace cp, but still precede all widget names with "cp". So using the widget is cp::cpWidget. This redundancy is ugly and pointless.

2) It would integrate much better with SFML if you implemented widgets as sf::Drawable. Example, class cp::Object : public sf::Drawable {...};

3) There does not appear to be a standard interface for handling an sf::Event. This enables the library's user to easily implement his or her own widgets, which is an important feature for any GUI library. Simply attempting to implement every last widget the user may wish for in his application would result in cpGUI being a massive library.

4) cpObject does not define a parent widget, just the sf::Window it is a part of. The sf::Window should be part of cpGuiContainer; another cpObject or cpGuiContainer should be the widget's parent.

You are referring to the old version. I fixed #1 a long time ago.

You can get the latest code through github (see project page). I think it references pdusen's repo. Mine (recruit0) should have the latest code though. The skeleton/framework should be pretty much done. All that's left is to implement the widgets (and fix existing ones, e.g. text_box works but is glitchy so is not done).

3

SFML projects / Ultimate Zombie Fighters

« on: September 19, 2010, 05:11:04 am »

For single player mode only make the weapon, zombie, vehicle, survivor attributes in a txt file

They are... although a XML file more specifically.

Is there gonna be split screen?

I vote for this as well. Although, this shouldn't be a high priority (there are many things that need to be developed first, see wiki).

Also... I'm pretty sure I promised you I would benchmark your game..

At the moment there's not much to benchmark. Once the game implements leaky spawn system (correctly) then there will be something to benchmark (hundreds or even thousands of active units on the map).

Lastly, have you thought about things like zombie cows? Or zombie crows

Yes, I've thought of other types of zombies (see the wiki). As for crows, that falls under zombies classified as "Kamikaze". I'm still undecided on the name, but it describes their aerial suicidal attacks. I believe there is room for more types of zombies though.

4

General / Running Program Without IDE

« on: September 02, 2010, 03:11:06 am »

The DLLs need to be in the same folder as the EXE. Or, you can put the DLLs in the system folder (I forget which since I use linux now).

5

General discussions / Should I go from SDL to SFML?

« on: September 01, 2010, 03:12:29 am »

You can clip with glScissor... Unless that's not what you're talking about.

6

General / Is a function way efficient for playing a new game, if lose?

« on: August 28, 2010, 12:50:56 am »

Sounds like you're trying to figure out how to handle multiple (macro) game states. Basically you need to reset everything (ball position, points, etc.). Off the top of my head, you could encapsulate (put) current code inside a loop and have a condition where if the player says "Quit" it exits the loop (this is a loop inside the game loop).

If everything's inside main, you really should at least create a function and move it outside (into another file). You could also use a switch statement to call the correct function depending on what the game state is (running, restart, stop, etc).

Based off of your question it sounds like you're not encapsulating (isolating) code. It's good practice to do because it makes it easier to manage.

Not sure but I hope the above was helpful.

7

SFML projects / Ultimate Zombie Fighters

« on: August 27, 2010, 04:43:30 pm »

I'm thinking that there could be a broadcast locating system...

Yeah that's wut i was thinking. Whenever weapons make a sound, it chains through and gets all the zombies to respond depending on if they'd hear it or not.

With spotting you, only zombies that can see that zombie should follow it.

Nice work on the wiki. Also good luck with cpGUI.

Thanks. It's not that complicated (not as complicated as UZF anyway). Most of my effort is going into making myself finish what I started.  :lol:

8

SFML projects / Tetris Clone

« on: August 26, 2010, 07:25:42 pm »

Congrats

9

General discussions / Should I go from SDL to SFML?

« on: August 26, 2010, 07:23:50 pm »

If you need to manage the code, then you should switch to SFML. SFML is more "automated" than SDL (i.e. there's less stuff you have to deal with). If code maintenance isn't an issue (unlikely), then don't bother.

10

Graphics / sf::Sprite FloodFill or Masking?

« on: August 25, 2010, 07:05:52 am »

I'm also interested in this function. I'll list below things that may help speed up the process (or not):

• OpenGL
• Masking
• Binary Search
• Spiral (box) search
• Scan line search
• Edge detection then polygon fill algorithm
• Memcpy()

11

SFML projects / cpGUI - Anyone interested in developing?

« on: August 25, 2010, 05:53:17 am »

Thanks for the support. And congrats on the baby.

Sorry I don't have much to show for it though. Most of it is in my head at the moment (I'll spend large amounts of time calculating in my head before I start spitting out code, unless it's imperative I produce code ASAP). I've been mostly calculating how to design everything and conceptual stuff like whether a block of buttons should count as a menu.

I realize that there is a lot that wasn't done efficiently.

I scanned your code and IMHO it looks like you had written it with minimal design in mind (if any), i.e. it looked like it was just thrown together (which makes sense with the 1-2 week creation period). Which is why I scrapped the current API and worked from the ground up while using your code as reference code (i.e. a "cache").

Starting from scratch made it easier to test IMO. With the old API deactivated, I didn't need to try to get the new and old to cooperate with each other (during production). And I could see how you solved certain problems (e.g. text input) and build from there.

I'm sure you've already come up with a way for the user to toggle on and off whether something is drawn or not.

Yes, widgets can connect/disconnect with a gui. Things have been designed to chain together now. There's even room for cpGUI to chain through libraries other than SFML (e.g. SDL and Allegro). Although code handling that will come much later.

I basically created the whole thing by myself in about a 1-2 week period

Someone mentioned that there's a bug with the drop down list class that allows them to select items after they've already selected one (and the menu disappears). I've yet to test it but now I know why there's a bug (you didn't finish coding it). It's no prob though, I'm currently working on the menu class and the timing is intriguing (I'll end up fixing the bug in the old code and propagating what I learn to the new).

12

General / Life-/Mana-bar

« on: August 24, 2010, 05:38:37 pm »

If SFML had a flood fill function, all you'd have to do is draw a horizontal line (correctly) then flood fill inside that.

13

Feature requests / Flood fill

« on: August 23, 2010, 03:10:58 pm »

Care to expand on that? Why not? We're provided functions to draw basic shapes yet not for flood filling?

14

General discussions / Blocking

« on: August 23, 2010, 03:04:40 pm »

The only thing you have to do is a loop with a sleep, waiting a specific event. If the app s blocked, nothing will un-block it, it must wait for a signal or something, no ?

It will wake up after however long you tell it to sleep. As in, it's not going to wake up from an event signal, but an alarm clock (which is "wrong" when it comes to event driven programming). The sleep() function (in any library) does not tell it to wait for a specific event (from the user), it means "block me for a minimum amount of time".

A blocking WaitEvent function is available in SFML 2.

Thanks for the addition in SFML 2.

15

General discussions / Input needed... v1.6 vs. SVN v2.0

« on: August 23, 2010, 02:23:28 am »

Looks interesting

I suggest using SFML 1.6 as it's more stable (and more tested). SFML 2 is still in development.

As for UI, I'm updating a GUI called "cpGUI" that should be ready for beta release in a week or 2. For more info, see:

http://www.sfml-dev.org/forum/viewtopic.php?t=1517&start=60