[ 3 / biz / cgl / ck / diy / fa / ic / jp / lit / sci / vr / vt ] [ index / top / reports ] [ become a patron ] [ status ]
2023-11: Warosu is now out of extended maintenance.

/vr/ - Retro Games


View post   

File: 535 KB, 1023x858, DPG - Asuka.png [View same] [iqdb] [saucenao] [google]
1498898 No.1498898 [Reply] [Original]

Never seen a programming thread on /vr/ before. You can consider programming retro I suppose, if we are all programming in like ANSI C or something. Dosbox, OpenRA, a bajillion doom source ports, all made by people like you and me. So would a programming thread work here? /g/ is too busy arguing over the OP's picture and waiting for the 300 post bump limit to actually get stuff done.

>> No.1498945

There was this one tripfag that tried to make a retro adventure game working under DOS. No idea what happened to him and his project, though.

>> No.1498963

I wonder if code works on /vr/, you think the mods would permit something like this?

>> No.1498976

>>1498898
>You can consider programming retro

No you can't. Fuck off.

>> No.1498979
File: 1.66 MB, 2711x4093, UltimateDoomPoster.jpg [View same] [iqdb] [saucenao] [google]
1498979

OP, if you can make a programming thread picture out of this, i'd be okay with that

>>1498976
I think he means in the sense of programming languages pre 1999 like ANSI C

>> No.1498984

>>1498976
>No you can't. Fuck off.

Yes you can actually.

There are things like BASIC on the Atari. Also things like ROMhacks, game mods, etc.

>> No.1498990

>>1498945
he was crazy

>>1498963
moot wouldn't do it for /agdg/, he's not gonna do it for /vr/

>> No.1499052

>>1498976
ever heard of assembly

>> No.1499050

>>1498990
if he made an imageboard solely for programming (like he did for business), i'm sure it would work out well

>> No.1499074

>>1498976
>retro game programming isn't retro

You realize modern-day programmers are 99% the reason Doom is as popular as it is, right?

>> No.1499082

>>1499074
Maybe you should make that point in the Doom thread. Most of us consider Doom just another game, and one with a near Sonic level irritating fanbase.

>> No.1499083

>>1499074
What? What?

>> No.1499282

>>1499083
in the butt.

>> No.1499306

68K assembler master race reporting in

trap 15
rts

>> No.1500326

Any good DOS C compilers still around? Allegro or SDL for DOS?

>> No.1500683

>>1499052
I still write assembly in my day job. Not necessarily retro.

>> No.1500687

>>1500326
Watcom or nothing. I assume OpenWatcom still has DOS targets but maybe it doesn't, I haven't bothered to look at it since they announced it.

As for Allegro or SDL... there is so much DOS programming source and it's so easy to write VGA games directly, there's no real need to use something like SDL; you'll probably spend more time trying to get a modern library like that to compile under DOS than it's worth. Just hit the VGA registers directly. It's more fun that way, too.

The hard part is the memory management. You'll want someone's code to open up "unreal" mode or similar, depending on what generation of DOS machines you're targeting.

>> No.1500965

>>1500687
i've been programming a game for years and i've been thinking of making a Windows 9x - DOS, and linux executable for the game you can download from the website. The DOS I assume will be the Windows 9x version, like Doom era DOS. Know where I can find some cool tutorials?

>> No.1500978

>>1500965
http://edn.embarcadero.com/article/20841
Get Turbo C from here, works with dosbox iirc

>> No.1501016

>>1500965
http://ftp.lanet.lv/ftp/mirror/x2ftp/msdos/programming/
http://bos.asmhackers.net/docs/pmode/unreal/Unreal.txt
http://textfiles.com/programming/

I fondly remember the Asphyxia tutorials and the ones in the "PC Game Programming Encyclopedia" which should both be on x2ftp.

The other thing that was essential was the big list of interrupt handlers someone had compiled.

There should also be a ton of old demoscene t-files around somewhere, maybe http://www.oldskool.org/ or http://hornet.org/

Also, it's worth reading the source to Wolf3D, Doom, Raptor; whatever's available. Especially Wolf is full of classic DOS game programming tricks.

>> No.1501026

Also, does anyone know a better place to talk about stuff like this anonymously? (not web forums with pseudonyms) /g/ is no good; too high traffic, and too broadly focused.

/vr/ is one of the only things of its sort that I read, but something like this with more focus on the technology of retro games (and demo scene) and less bullshit would be great.

>> No.1501034

>>1498898
There are people still playing quake III and other very hackeable/mod-able games, how about a 4chan map or new model-character

>> No.1501037

>>1501034
>how
*what

>> No.1501039

>>1499050
>not being aware of the cesspit that is /prog/

>> No.1501046

>>1501026
>>>/vg/agdg/

>> No.1501043

>>1500683
really ? what still uses assembly?just curious

>> No.1501049

It's not like you can't talk about programming in /vr/, but the question is why would you want to. Eventually the discussion would be steered into something that's not retro material and "NOT-RETRO!" police would just come in and shit all over the place.

>> No.1501057

>>1501049
There can be rules like:
1. For the most part only Compilers and Libraries pre-1999 are allowed
2. The objection to the rule is if you are making a source port to something pre-1999 but with a language released after that date

>> No.1501060

I'm trying to learn Quake C by looking at the original QC source and the Team Fortress mod. I hope to create a mission pack with a completely linked world that focuses on exploration, sort of like Metroid.

Anyone got any suggestions on where to look for Quake C documentation? I mean, it doesn't look hard, but I could use some tips from those who've gone before me.

>> No.1501058

Any good libraries for psx homebrew development? Also: resources, sites, docs, examples, tutorials, books, etc?

>> No.1501113

>>1501043
I mostly deal with it code generation in compilers, as well as parts of the runtime system that either need to do weird tricks, or a specific optimization.

I know people in the game industry who will drop down to it occasionally, although compiler intrinsics for stuff like AVX have gotten good enough that most people concerned with performance only need to read assembly (to verify the compiler is emitting the right thing) rather than writing it. I encountered the same thing in HFT in the finance world.

Finally, since people are still making Z80s, I assume there are still people in embedded doing a fair bit of assembly, but I don't know any personally.

>> No.1501124

http://www.mediafire.com/download/x3k5k6z7unonnou/Borland+Turbo+C%2B%2B+v3.0+%28C+Compiler%29.rar

Here's a C/C++ compiler for dos, will work in dosbox. Have fun.

>> No.1501134

>>1500978
>Borland Turbo C
fuck me m8, thats some nostalgia there. thats how I learned programming; don't understand a syntax/function? right click that shit.
Someone needs to make a mode like that for emacs.

>>1501058
If I'm not mistaken, PSX had pretty convenient CISC shit going on with its coprocessors, so assembly programmers could do graphics/SIMD shit without any hassle, I dunno of any libraries though.
It would be worth learning MIPS assembly because it is simple, however, a compiler will probably produce quicker code than hand-rolled shit.
My advice would be to find a torrent of the original SDK instead of searching for tutorials/reverse engineered info.
underground-gamer had a kick ass torrent for SDKs of all consoles

>> No.1501146

>>1501043
drivers usually require some assembly I believe, micro-controllers and highly real-time applications probably require it too for certain things
some crazy hacks require hand rolled assembly, especially in the demo-scene, where clock cycle-counting is required

>>1501134
also, for the people interested in DOS compilers, I dunno if Turbo C is the best choice.
As far as 16 read-mode code goes, its pretty good, but I've heard Open Watcom is superior.
If you want to do 32 bit protected mode shit like quake, use DJGPP, which is the GNU Compiler Ported to dos.

>> No.1501159

>>1501146
what specific file get's downloaded and how is it used?

>> No.1501258

>>1501159
use the zip picker
http://www.delorie.com/djgpp/zip-picker.html

the main programs you want are gcc (the c compiler) and binutils (linker, assembler, disassembler)
RHIDE is a Turbo C++ lookalike, which is probably better for people who aren't familiar with gcc's command line interface, and is more "friendly" than emacs

gcc is used by compiling the individual .c files into .o, then linking them together into an executable.
you also provide additional info like what libraries you are using, where your include directories are, its all in the manual though

gcc -c main.c input.c graphics.o
gcc -o main.exe main.o input.o graphics.o

As far as vga is concerned, I remember seeing a lot of Mode13h, ModeX VGA tutorials online, but Allegro had pretty good DOS support.

>> No.1501417

>>1501258
so if we make an OP post to use for future references, what would we do? Would we do like:

/vr/ programming thread

C/C++ DOS Compiler:
http://www.mediafire.com/download/x3k5k6z7unonnou/Borland+Turbo+C%2B%2B+v3.0+%28C+Compiler%29.rar

Allegro 3 DOS Game Library:
http://alleg.sourceforge.net/old.html

Any programming from something that is pre 1999 or porting something (such as Doom or Quake) to a modern language is allowed.

What are you working on, /vr/?

>> No.1501472

>>1501060

Do you have the Black Book of Graphics Programming?

http://www.drdobbs.com/parallel/graphics-programming-black-book/184404919

>> No.1501497

How do I get Linux to select all files that start with "file" and end with any number of digits?
Right now I have file*[0-9]* but I'd like something more robust.

>> No.1501798

>>1501497
This depends on your shell, not your operating system, and is off-topic here. Read your shell's manpage on globbing.

>> No.1501817

>>1501417
Apparently Open Watcom still ship binaries for DOS, so I would add that, because even though Turbo C++ had a great IDE, Watcom always crushed it as a compiler.

http://www.openwatcom.org/index.php/Download

I might dig up some old DOS game code I wrote and see if I can manage to make it build both for Linux and DOS. I did have that going at one point, but the Linux code all used SVGAlib and OSS! (And at the time I cursed SVGAlib for being too high level. Ha!)

>> No.1501823

Oh boy, a DPT on /vr/

This might be good...

>> No.1501856

it's been here for a couple days iirc, anyways we aren't measuring dicks of waifus in this thread, so you can go to /g/ for that if thats what you came for

>> No.1501859

>>1501856
I'm actually running away from that sort of shit, /g/ is "Vomitive Shithole MkII" for me now.

>> No.1501860

>>1501859
then it's all good lol

in C89, I got a char, well for some reason I get the error:
warning: assignment makes pointer from integer without a cast [enabled by default]

any ideas?

>> No.1501863

>>1501860
I think I know what the problem is, show me the code.

>> No.1501881

>>1501863
--------------------------------------------------------------
int initPlayer() {
/* Initialize player variables */
player.name = "PLAYER";
player.ID = 0;
player.x = 0;
player.y = 0;
player.w = 16;
player.h = 32;
player.a = 1;
player.a_t = 13;
/* Initialize player status variables */
player.onground = true;
player.walking = false;
player.falling = false;
player.jumping = false;
/* Load image (if it doesn't already exist in memory) */
if( imagePlayer == NULL ) {
printf("player image not loaded, loading it...\n");
char *file = "player.png";
imagePlayer = load_image(file);
}
/* output to console where the player will spawn */
printf( "%s initialized! will spawn at: %d,%d\n", player.name, player.x, player.y );
}
-----------------------------------------------------------------
SDL_Surface* load_image( char *filename ) {
/* Load an image onto an SDL_Surface */
SDL_Surface* temp = IMG_Load(filename);
/* Create an optimized version of what was just loaded */
SDL_Surface* opt_temp = SDL_DisplayFormat( temp );
/* Unload the original temp image */
SDL_FreeSurface( temp );
/* Return the optimized image */
return opt_temp;
}

>> No.1501889

>>1501881
well I'm stumped. What is the exact line the warning happens at?

>> No.1501891

>>1501889
it's in this
if( imagePlayer == NULL ) {
printf("player image not loaded, loading it...\n");
char *file = "player.png";
imagePlayer = load_image(file);
}
right at the
char *file = "player.png";

>> No.1501896

>>1501891
weird... that shouldn't happen. Try prepending const there.

>> No.1501901

>>1501896
same problem

>> No.1501905

>>1501901
OK this really shouldn't be happening... I'm gonna have to look at the entire project files, if that's ok.

>> No.1501909

Love C - compact, precise and often deadly. Peter Van Der Linden's "Deep C Secrets" highly recommended.

>> No.1501914

>>1501881
This code isn't C89, by the way. For example, you can't declare variables in arbitrary parts of a block in C89. Also, what are the types of the globals you're using there? (player and imagePlayer... BTW, making these global is some sloppy shit)

>> No.1501921

>>1501891
Are you sure it's on the char* declaration? It looks more like you haven't given the prototype of load_image in advance, in which case it's going to assume it returns an int rather than a pointer. Always declare your prototypes or declare functions in reverse order of use.

>> No.1501925

>>1501921
ah now that's more like it.

>> No.1501926

>>1501043
google this: lft craft
Also, some people still make games for Amiga, and older home computers.

>> No.1501928

>>1501926
Heh, I plan to start a third game engine project in pure x86 assembly just for the heck of it. It's fun to play around with it.

>> No.1501932

>>1501921
>>1501925
it worked, i just changed the order they were in the file

>> No.1501943

>>1501932
lrn2prototype

>> No.1502273

>>1501928
sounds crazy

>> No.1504126

>>1501928
what other engines do you have?