• What are you working on? V7
    2,001 replies, posted
I remade my main menu background...again. :D [img]http://i46.tinypic.com/dgt5k0.jpg[/img]
Would that be jallen? :v:
Wait shit that's me
[QUOTE=Jallen;19797305]Wait shit that's me[/QUOTE] It is?
Guys what's the best way to use a C# program as input for a C++ program? I'm making a graphics application and I want to be able to pop up C# forms to take input. I was thinking writing to a file in the C# app then reading it in the C++ app, but that could be difficult due to the C++ trying to read it before the user has entered the input / the file has finished being writing. An alternative method could be some kind of network based solution, basically sending the other program a packet, but that seems like overkill, especially since I'm a serious noob when it comes to network programming. So what's the best / simplest way to do this?
[QUOTE=Jallen;19800636]Guys what's the best way to use a C# program as input for a C++ program? I'm making a graphics application and I want to be able to pop up C# forms to take input. I was thinking writing to a file in the C# app then reading it in the C++ app, but that could be difficult due to the C++ trying to read it before the user has entered the input / the file has finished being writing. An alternative method could be some kind of network based solution, basically sending the other program a packet, but that seems like overkill, especially since I'm a serious noob when it comes to network programming. So what's the best / simplest way to do this?[/QUOTE] In Linux you can let one program get its stdin from another programs stdout. You could try to do something similar. The C++ program starts the C# program and listens to its output. When the user enters something in the C# program it just outputs it to stdout.
[QUOTE=Jallen;19800636]Guys what's the best way to use a C# program as input for a C++ program? I'm making a graphics application and I want to be able to pop up C# forms to take input. I was thinking writing to a file in the C# app then reading it in the C++ app, but that could be difficult due to the C++ trying to read it before the user has entered the input / the file has finished being writing. An alternative method could be some kind of network based solution, basically sending the other program a packet, but that seems like overkill, especially since I'm a serious noob when it comes to network programming. So what's the best / simplest way to do this?[/QUOTE] The simplest inter-process communication you can do is to use stdin, stdout and stderr. The .NET Process class facilitates this kind of functionality in a simple, nice stream-based fashion. This is also the only true multi-platform solution. There exists IPC alternatives both for Unix based systems and Windows, but I'm not sure if any of them overlaps in a fashion that allows Mono and whatnot to emulate both with the same interface (apart from using the three I/O standard pipes).
Ok I did a little research and it sounds like you are describing a pipeline, I'm looking at it in more detail now. Thanks. [url]http://en.wikipedia.org/wiki/Pipeline_%28Unix%29[/url] Trying to find out how to actually do it.
It seems that i have too much time on my hands. [media]http://www.youtube.com/watch?v=QCfdKJkYHUQ[/media] [img_thumb]http://www.filez.muffinz.eu/download/Temp-2010-01-23-19-37-25-97.png[/img_thumb] Note: In main menu (same as movie) game plays itself. :v:
[QUOTE=Jallen;19801374]Ok I did a little research and it sounds like you are describing a pipeline, I'm looking at it in more detail now. Thanks. [url]http://en.wikipedia.org/wiki/Pipeline_%28Unix%29[/url] Trying to find out how to actually do it.[/QUOTE] Pipes are usually just used for transmitting buffers between different threads that have some shared memory mapped. If your C++ program executes some C# program, then this would be ideal, but perhaps not if they operate independently. Many programs out there that need to communicate between other programs running (and for some reason don't want to use the standardized dbus framework) just communicate over sockets. Sure, they are probably running on the same local host, but the convenience of sockets is worth a lot.
[QUOTE=Jallen;19801374]Ok I did a little research and it sounds like you are describing a pipeline, I'm looking at it in more detail now. Thanks. [url]http://en.wikipedia.org/wiki/Pipeline_%28Unix%29[/url] Trying to find out how to actually do it.[/QUOTE] Have the C# process open the C++ program and set all the redirect flags to "true" for the ProcessStartInfo (RedirectStandardError, RedirectStandardOutput, RedirectStandardInput). Put the input either as command line arguments or write to stdin. For example, if your C++ program is supposed to work both from the command line and as a child process, you can have it accept a flag among the command line arguments telling it to parse input as commands and only output vital data (often in parsable form if it's non-trivial). Remember, you're not limited to text. Anyway, the C++ program reads input from std::cin and outputs to std::cout. If anything goes wrong, you can signal that by writing to std::cerr. Back in the C# process, simply write to stdin, then read from stdout and stderr.
[img]http://filesmelt.com/dl/screenie13.png[/img] Got level ending and collecting piglets for score :3:
Trying to conceptualize a game idea I had. Basically it's a 2D top-down space sim. But instead of having distinct sectors, it's all one big galaxy. Really the only difference is that you can fly in the spaces between sectors. Also, there are no gates, you can warp to whatever location you want to as long as you know the coordinates. I'd like for the universe to be procedurally generated, but I'm not sure how feasible that is. It would be nice for open-ended gameplay but it would make a story mode difficult, if not impossible. I also imagine it's difficult programmatically speaking.
[QUOTE=iPope;19804048] *image* Got level ending and collecting piglets for score :3: [/QUOTE] Percy pigs! I used to love those when I was little.
[QUOTE=Ortzinator;19804462]Trying to conceptualize a game idea I had. Basically it's a 2D top-down space sim. But instead of having distinct sectors, it's all one big galaxy. Really the only difference is that you can fly in the spaces between sectors. Also, there are no gates, you can warp to whatever location you want to as long as you know the coordinates. I'd like for the universe to be procedurally generated, but I'm not sure how feasible that is. It would be nice for open-ended gameplay but it would make a story mode difficult, if not impossible. I also imagine it's difficult programmatically speaking.[/QUOTE] :argh: [quote=me] It's a top-down asteroid belt with high level continuity to maximize immersion. Hopefully :D [/quote] [quote] [img]http://filesmelt.com/downloader/orbit2.gif[/img] [/quote] [editline]01:07PM[/editline] But seriously, I really want to get back around to it... Working on an experimental program dealing with stocks right now.
Look what I got. 35 shillings no less! [img]http://imgur.com/zwmTw.jpg[/img] [IMG]http://imgur.com/UNMlG.jpg[/IMG]
[img]http://www.cubeupload.com/files/4df400yamarpeople.png[/img] Made a large panorama to see if the AI is working correctly and the randomization is randomizing correctly. It has a few flaws still (see the bunch of bald guys in a row) and pants / shoes aren't implemented yet but overall I'm very satisfied with them. Tomorrow I'm gonna make a video to show you how sweet they look in action. But I'm not here to tell you how sweet the pedestrians are - I want ideas! If you think a specific hat / hairstyle would fit the pixel people do say so. If you think they need something extra please tell that as well so I can be sure that you will like it.
[QUOTE=Ortzinator;19804462]Trying to conceptualize a game idea I had. Basically it's a 2D top-down space sim. But instead of having distinct sectors, it's all one big galaxy. Really the only difference is that you can fly in the spaces between sectors. Also, there are no gates, you can warp to whatever location you want to as long as you know the coordinates. I'd like for the universe to be procedurally generated, but I'm not sure how feasible that is. It would be nice for open-ended gameplay but it would make a story mode difficult, if not impossible. I also imagine it's difficult programmatically speaking.[/QUOTE] You could have your own pre-made area that the story is within, and the area outside that is randomly generated and stored once the player exports it, or have random wormhole appear the in the pre-made space that links to randomly generated sectors of space that are randomly generated until the player passes through the wormhole again to return to the pre-made space and then the wormhole collapses.
After working with a 56megs xml file I am now hate xml and how wasteful it is. It takes over 60 seconds to parse the xml. The same file in csv format is only 12megs takes about 10 seconds to parse.
People seem to have this crazy idea that procedurally generated means randomly generated. It's simply not the case. You still control how things are generated, from very high to very low level control depending what you need. You don't magically loose the ability to craft levels how you please. Also a good story shouldn't need an awful lot of stuff to be set in stone. It should be more about the characters, events and their interactions than specific level design. It can even be better this way as the world can be easily adapted to the story as it is played out rather than the game forcing a way in which you play the story. [editline]12:43PM[/editline] [QUOTE=Hibame;19811123]After working with a 56megs xml file I am now hate xml and how wasteful it is. It takes over 60 seconds to parse the xml. The same file in cvs format is only 12megs takes about 10 seconds to parse.[/QUOTE] XML is a document format, it works OK for that, but anything else is just insane. Also do you mean csv?
[QUOTE=windwakr;19795338]I've started learning OpenGL over the past day or so. I've ported the first couple NeHe tutorials to assembly. The ones that are provided with the tutorials are in that horrible MASM syntax, so I just ported from the C++ to FASM syntax assembly. 433 lines of assembly and this is what I got: [IMG]http://filesmelt.com/dl/opengl_nehe_assembly.PNG[/IMG] Was a pain in the ass. So many little mistakes had me constantly debugging it. But now that I have the basic framework laid out, it should be easier to add more to it. OpenGL is quite confusing.[/QUOTE] It's just a 'state machine' set-up. It's not really confusing at all.
[QUOTE=blankthemuffin;19811326] XML is a document format, it works OK for that, but anything else is just insane. Also do you mean csv?[/QUOTE] It is a bunch of similar yet different files that are given by suppliers weekly. Yes I did mean csv.
[QUOTE=Hibame;19811123]After working with a 56megs xml file I am now hate xml and how wasteful it is. It takes over 60 seconds to parse the xml. The same file in csv format is only 12megs takes about 10 seconds to parse.[/QUOTE] XML is used for portability, not speed or size.
What [i]the fuck[/i] are you putting in an XML text file that causes it to be 56mbs? [editline]05:19PM[/editline] [QUOTE=Namelezz!;19807016][img]http://www.cubeupload.com/files/4df400yamarpeople.png[/img] Made a large panorama to see if the AI is working correctly and the randomization is randomizing correctly. It has a few flaws still (see the bunch of bald guys in a row) and pants / shoes aren't implemented yet but overall I'm very satisfied with them. Tomorrow I'm gonna make a video to show you how sweet they look in action. But I'm not here to tell you how sweet the pedestrians are - I want ideas! If you think a specific hat / hairstyle would fit the pixel people do say so. If you think they need something extra please tell that as well so I can be sure that you will like it.[/QUOTE] It'd be great if you could alternate the skin colour a tiny bit and base clothing on that to show different cultures. (Muslim headscarfs, black gangsters, white nerds) Oh, and maybe have gangsters in a group. Because gangsters are in groups.
[QUOTE=Ortzinator;19816355]XML is used for portability, not speed or size.[/QUOTE] As well as a simple, human-readable markup. It's only good for small databases of information, or uses on the web, in my opinion. If you have a 56MB XML file, you probably shouldn't be using XML.
[QUOTE=BlackPhoenix;19766388][media]http://www.youtube.com/watch?v=U5yWmuqHshI[/media] I'm working on autopilot for my spacecraft. It guides it from ground to space, in 15 minutes. From 0 km/sec to 7.7 km/sec (orbital velocity). There's several phases, atmospheric engines and rocket engines, and scramjets. Sorry for the video quality, but there seems to be no other way to capture video without affecting simulator FPS. The problem: FRAPS and pretty much all other screen grabbing software will decrease FPS. 25 FPS is [B]way[/B] too low for this to work precisely. [B]Why:[/B] at 25 FPS spacecraft travels roughly 300 meters in [B]one frame[/B], during liftoff. It usually runs at 120 FPS, which gives jump of less than 50 meters. If you have any idea how to do it better than using external recorder, do tell ([B]although[/B] I'm gonna record video output from videocard directly later, without distortions)[/QUOTE] Shouldn't you be using a fixed time-step for your logic.
move by delta time
No, you should be using a fixed time step. A large or fluctuating delta time will induce errors depending on your integrator. [url]http://gafferongames.com/game-physics/fix-your-timestep/[/url] [url]http://turborilla.com/timestepping.html[/url] [url]http://www.flipcode.com/archives/Main_Loop_with_Fixed_Time_Steps.shtml[/url]
I've been working on a small OS project for a while, and I need to implement the setjmp and longjmp functions. I pulled up newlib's implementation of setjmp and longjmp, and I found some absolutely horrifying code. It uses AT&T syntax for the asm, which requires you to place a percent character before register names. However, the goons who wrote this thought that writing %eax was too much effort, so they decided to run the ASM source through the C preprocessor so they could use some delicious defines. Here's a snippet from newlib/libc/machine/i386/i386mach.h: [cpp] #define __REG_PREFIX__ % /* ANSI concatenation macros. */ #define CONCAT1(a, b) CONCAT2(a, b) #define CONCAT2(a, b) a##b /* Use the right prefix for global labels. */ #define SYM(x) CONCAT1(__USER_LABEL_PREFIX__, x) /* Use the right prefix for registers. */ #define REG(x) CONCAT1(__REG_PREFIX__, x) #define eax REG(eax) #define ebx REG(ebx) #define ecx REG(ecx) #define edx REG(edx) #define esi REG(esi) #define edi REG(edi) #define ebp REG(ebp) #define esp REG(esp) #define st0 REG(st) #define st1 REG(st(1)) #define st2 REG(st(2)) #define st3 REG(st(3)) #define st4 REG(st(4)) #define st5 REG(st(5)) #define st6 REG(st(6)) #define st7 REG(st(7)) #define ax REG(ax) #define bx REG(bx) #define cx REG(cx) #define dx REG(dx) #define ah REG(ah) #define bh REG(bh) #define ch REG(ch) #define dh REG(dh) #define al REG(al) #define bl REG(bl) #define cl REG(cl) #define dl REG(dl) #define mm1 REG(mm1) #define mm2 REG(mm2) #define mm3 REG(mm3) #define mm4 REG(mm4) #define mm5 REG(mm5) #define mm6 REG(mm6) #define mm7 REG(mm7) [/cpp] Now with these awesome macros, they can save [b]a whole freakin' keystroke[/b] when coding their ASM.
[QUOTE=blankthemuffin;19817931]Shouldn't you be using a fixed time-step for your logic.[/QUOTE] [editline]10:13AM[/editline] For some reason my previous reply didn't post; I was saying that I'm using variable time step, cause simulator uses variable time step; and 100 FPS requirement is there because of how fast the aircraft travels. So no matter if it's fixed or variable, it has to be 100 or more; and also physics in this simulator are major cause of FPS drop (they are in same thread).
Sorry, you need to Log In to post a reply to this thread.