Post screenshots of stuff you're working on!

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Post screenshots of stuff you're working on!

«‹›203 »

Tres Burritos: Sep 3, 2009

Internet Janitor posted:

Looks a bit better in motion.

This looks really neat. Are all the lines curved slightly to imitate a CRT? Definitely post up a .gif or video of it running.

# ? Dec 2, 2013 22:26

Adbot: ADBOT LOVES YOU

# ? May 9, 2024 05:09

go play outside Skyler: Nov 7, 2005

Natrox posted:

For the past months in my spare time, I have been working on a toy virtual machine. The instruction set is very much based on the original x86/x87 instruction set, with a few instructions extra or missing. Programs are encoded in a byte code format, allowing an operation code, flags and two operands. The virtual machine runs the programs using a computed goto table, which makes for ugly but relatively fast code. It has 32 registers, a 1MB stack and a user-definable heap area. I am currently trying to implement the LEA instruction. As far as I know, the LEA instruction can be expanded to multiple MOV operations, which should make it pretty straightforward.

Here's a screenshot of my virtual machine running a Mandelbrot demo;

Programs can be made by hand using byte code, or they may be created in an assembler language specific to my virtual machine.

Here is the source of the Mandelbrot demo, if you are interested;
http://paste.pm/cbk.asm

Should be easy to understand for anyone familiar with x86-assembly.

Very interesting stuff. I always love people who make stuff just for the heck of it. You should post your source code somewhere or, even better, write a blog about it, explaining your process. I'm sure a lot of people would find it useful and interesting. I know I would.

# ? Dec 2, 2013 22:46

Natrox: Dec 2, 2013

Sir Davey posted:

Very interesting stuff. I always love people who make stuff just for the heck of it. You should post your source code somewhere or, even better, write a blog about it, explaining your process. I'm sure a lot of people would find it useful and interesting. I know I would.

I am planning on making the code available on a GitHub repository sometime soon, hopefully by the end this month. Just haven't had the time to write proper documentation yet. For the future, I am looking into porting a small/limited C or Java compiler to my architecture.

# ? Dec 2, 2013 23:02

go play outside Skyler: Nov 7, 2005

Natrox posted:

I am planning on making the code available on a GitHub repository sometime soon, hopefully by the end this month. Just haven't had the time to write proper documentation yet. For the future, I am looking into porting a small/limited C or Java compiler to my architecture.

Well, it's never a good idea to assume you're going to write the documentation. I've been through this a million times. It's better to publish undocumented, ugly and buggy code than not publish anything at all! Nobody's going to judge you. Just spend 10 minutes writing a readme explaining what it does and that's already better than nothing.

# ? Dec 2, 2013 23:43

Natrox: Dec 2, 2013

Sir Davey posted:

Well, it's never a good idea to assume you're going to write the documentation. I've been through this a million times. It's better to publish undocumented, ugly and buggy code than not publish anything at all! Nobody's going to judge you. Just spend 10 minutes writing a readme explaining what it does and that's already better than nothing.

Perhaps I will do that if I really can't finish the documentation in a timely matter. I would just like to make it a habit of myself to document my code, even if it's for a pet project. I work with undocumented code almost daily, and it sometimes really annoys me when I cannot find out what a piece of code is supposed to do. But you're probably right, it's better than having an empty GitHub. :v:

# ? Dec 2, 2013 23:55

Internet Janitor: May 17, 2008; "That isn't the appropriate trash receptacle."

Tres Burritos posted:

This looks really neat. Are all the lines curved slightly to imitate a CRT? Definitely post up a .gif or video of it running.

Thanks!

The curvature is mainly just there to add a little visual interest, but it does make me think of CRTs a bit. I took a stab at recording a quick gif:

Obviously it's a bit more interesting with multiple players.

# ? Dec 3, 2013 05:51

Tres Burritos: Sep 3, 2009

Internet Janitor posted:

Thanks!

The curvature is mainly just there to add a little visual interest, but it does make me think of CRTs a bit. I took a stab at recording a quick gif:

Obviously it's a bit more interesting with multiple players.

drat that looks slick. What's it written in? Do you mind talking about how you achieved that effect?

edit: Hmmm looks like some kind of fisheye effect?

edit2: That little judder that happens when you hit a wall is such a good touch.

Tres Burritos fucked around with this message at 06:05 on Dec 3, 2013

# ? Dec 3, 2013 05:59

Internet Janitor: May 17, 2008; "That isn't the appropriate trash receptacle."

It's written in humble Java2D- the drawing API which comes stock with Java.

Everything is drawn as a series of polygons, and I transform each of their vertices before they are rendered by converting them to polar coordinates relative to the center of the screen, scaling the resulting radius by its hyperbolic tangent and then converting back to cartesian coordinates. The code looks something like this:

code:

double tx = x - screenwidth;
double ty = y - screenheight;
double r  = Math.sqrt(tx*tx + ty*ty);
double a  = Math.atan2(ty, tx);
double sz = screenwidth * 1.8;
double hr = sz * Math.tanh(r / sz);
x = screenwidth  + hr * Math.cos(a);
y = screenheight + hr * Math.sin(a);

Just a nice little trick I picked up in a data visualization class.

The game is actually a tech demo for a really stupid idea I had over thanksgiving. I wrote a stripped-down ultra-minimal and totally generic thin client for a game which does almost nothing but pump keyboard/mouse events to a server and render filled polygons it's sent vertices for, and then essentially all the work is done server-side. The result is a little jittery over an internet connection but still works much better than you'd expect. Coding the server-side game logic is very easy, as the server sees a single global view of everything and doesn't have to worry about clients falling out of sync. This approach is, of course, pretty much insane for a fast-paced action game but could be a really neat solution for turn-based strategy games or the like. The art style I'm using for CTF basically emerges from the limitations that I can only draw solid-colored polygons and must minimize the number of vertices sent per frame. I still have a few more ideas for making it feel a little more "juicy".

For the curious, here is a pastebin of the client code I'm using: http://pastebin.com/raw.php?i=520GKb3H

I'll probably put the whole prototype up on github in a few days.

# ? Dec 3, 2013 06:18

Woodsy Owl: Oct 27, 2004

Internet Janitor posted:

cool beans

The walls are actually composed of many individual polygons, right?

# ? Dec 3, 2013 06:29

Internet Janitor: May 17, 2008; "That isn't the appropriate trash receptacle."

Woodsy Owl: Correct- that's necessary to get the appearance of curved lines as they are distorted. This is made much more obvious when you bump into the walls and I add some wiggle to all the vertices. I'm still playing with the right balance of minimal vertices versus enough to get a smooth effect.

# ? Dec 3, 2013 06:31

Woodsy Owl: Oct 27, 2004

Internet Janitor posted:

Woodsy Owl: Correct- that's necessary to get the appearance of curved lines as they are distorted. This is made much more obvious when you bump into the walls and I add some wiggle to all the vertices. I'm still playing with the right balance of minimal vertices versus enough to get a smooth effect.

Is the animation this smooth in the client? Do you get a pretty stable framerate with 2D in Java?

This is cool as hell, by the way.

# ? Dec 3, 2013 06:35

Internet Janitor: May 17, 2008; "That isn't the appropriate trash receptacle."

Oh yeah, Java2D is actually quite zippy. It's hardware-accelerated on most platforms. The GIF I posted is recorded at 20fps, which is the framerate the game currently runs at. Java2D can easily handle a silky-smooth 60fps for something like this, but I go lower than that due to network bandwidth limitations, the real bottleneck. I've done some experiments with as many as four players connecting to a server via the internet and the game still remains playable. On a LAN I can probably support quite a few more.

# ? Dec 3, 2013 06:55

Jewel: May 2, 2009

Internet Janitor posted:

Oh yeah, Java2D is actually quite zippy. It's hardware-accelerated on most platforms. The GIF I posted is recorded at 20fps, which is the framerate the game currently runs at. Java2D can easily handle a silky-smooth 60fps for something like this, but I go lower than that due to network bandwidth limitations, the real bottleneck. I've done some experiments with as many as four players connecting to a server via the internet and the game still remains playable. On a LAN I can probably support quite a few more.

It's hard to parse your original post but I think you said you're sending the vertex positions over? Why?

# ? Dec 3, 2013 07:46

Woodsy Owl: Oct 27, 2004

Jewel posted:

It's hard to parse your original post but I think you said you're sending the vertex positions over? Why?

I'm speculating here, but maybe this is so he could manipulate the map server-side and the manipulations would be dished out to each client. Then maybe the clients don't have to keep a copy of the map locally, maybe. Maybe.

Internet Janitor: if a player bumps into a wall, will all the other players' clients show the wall-ripple effect too?

# ? Dec 3, 2013 07:58

Internet Janitor: May 17, 2008; "That isn't the appropriate trash receptacle."

I send vertices to the client because ALL the client knows how to do is render polygons and send the server input events. The server spoonfeeds each client with every line they will draw for every frame of the game. Take a look at the code I linked for the client- it's only about 150 lines and contains absolutely no game logic. It's like minimalist vector-based VNC. For CTF this amounts to around 5kb worth of data per frame.

# ? Dec 3, 2013 08:02

hendersa: Sep 17, 2006

There's something that I've looked at on and off for a while now, and I finally was able to throw a solid day or two into it over the holiday weekend:

I added the start of a voxel rendering pipeline into the original NES's PPU. I'm adding the pipeline into the FCEUX emulator's PPU implementation. The general idea is that voxel position metadata is associated with particular tiles in the pattern tables in the PPU. As the background is rendered from the pattern tables and the sprites are added, the metadata is consulted to determine the +Z and -Z size of the voxel rendered at a particular screen position. Each voxel is not necessarily a cube, but rather a rectangular prism with its length determined by the Z position of its near and far faces. The color of the voxel is based on the color of the original pixel as determined by the PPU's palette lookup logic.

I put together a short clip to show some aspects of it in action: https://www.youtube.com/watch?v=BD2DCsItk8E

# ? Dec 3, 2013 08:10

Internet Janitor: May 17, 2008; "That isn't the appropriate trash receptacle."

In case anybody is interested in playing with it or skimming the source, I put VectorLand on GitHub. The server is sort of hastily thrown together, so please be gentle.

# ? Dec 3, 2013 23:17

Tres Burritos: Sep 3, 2009

So I've been working on making some kind of ... editor thing to play with geometry in Three.js.

I've got a dialog creation system set up and a translation handle system.

Also for some reason GifCam just won't show the Y Axis arrow :shrug:

.

edit:vvvvv Thanks! vvvvvv

That is really weird, all I had to do was set it to not "pure" green and now it's just fine. Huh.

Tres Burritos fucked around with this message at 01:43 on Dec 4, 2013

# ? Dec 4, 2013 01:05

Suran37: Feb 28, 2009

Tres Burritos posted:

So I've been working on making some kind of ... editor thing to play with geometry in Three.js.

I've got a dialog creation system set up and a translation handle system.

Also for some reason GifCam just won't show the Y Axis arrow .

Seeing as it is usually green I'm guessing it may be keying it. Seems a little high tech for a gif recorder though.

# ? Dec 4, 2013 01:14

THE PLATFORM MASTER: Jun 3, 2008

I've been working on a disassembler since I got sick of IDA having the world's shittest interface. The backend is in Haskell (Data.Macho + Hdis86) and the frontend is JS in a browser. I'm in so far over my head it isn't funny, but at least I got something working!

# ? Dec 4, 2013 07:24

Natrox: Dec 2, 2013

Sir Davey posted:

Very interesting stuff. I always love people who make stuff just for the heck of it. You should post your source code somewhere or, even better, write a blog about it, explaining your process. I'm sure a lot of people would find it useful and interesting. I know I would.

I decided to release the source of my virtual machine before I started work on the formal documentation.

You may find it here:
https://github.com/Natrox/Raptor86

I have added some examples to the "assembler" folder. The assembler's source code will not be released, simply because it is a rushed mess. The assembler uses FLEX to parse a ".rasm" file, and it is somewhat strict. You should be fine if you follow the style of the example files.

The most complex example is "proceduralgrass.rasm". It generates a procedural grass texture, by drawing each grass blade, and then applies a box blur;

Hopefully, someone will find it interesting to play around with this thing. I would love to see the things other people could create with this. You are free to use any code from my virtual machine, or use it as a basis for your own (if anyone is interested in building their own virtual machine).

# ? Dec 4, 2013 23:12

hendersa: Sep 17, 2006

Second stage of the NES PPU voxel pipeline "master plan":

Things are coming along nicely. That's the ARToolkit framework, but I've been hacking on it to get it to play nice with the existing OpenGL rendering of the NES emulator. I don't use GLUT, but rather the OpenGL support of SDL, so I had to rip some ARToolkit out to properly set up scaling and translations and the like. I need to pick up a lazy Susan to mount the AR marker to so that I can rotate it more easily.

# ? Dec 5, 2013 00:36

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

What's the master plan?

# ? Dec 5, 2013 01:14

Tivac: Feb 18, 2003; No matter how things may seem to change, never forget who you are

I've been experimenting with node-webkit and writing the twitter client I always wanted but never had. I :love:

twitter lists, but most clients barely even support them in a useful way. So now I'm doing something about it.

It's still pretty rough-and-tumble but I'm starting to be able to use it as my daily twitter client for reading. Still doesn't have any writing short of retweeting things though.

# ? Dec 5, 2013 01:18

hendersa: Sep 17, 2006

Suspicious Dish posted:

What's the master plan?

Well, I guess there are six parts:

1. Get the start of the voxel pipeline in place within an emulator as a proof of concept.
2. Figure out how to integrate ARToolkit into the emulator for augmented reality support.
3. Establish the shadow memory in the PPU to provide the proper tile metadata for voxel positioning data.
4. Populate the metadata with tile information that makes it all look 3D-ish.
5. Port the whole shot to a BeagleBone Black once TI gets around to getting their OpenGL acceleration working.
6. Document the whole thing and provide a system image with source code for educational purposes.

Also, I put together a quick video: https://www.youtube.com/watch?v=DJKqzBSx3yk

# ? Dec 5, 2013 05:30

Jewel: May 2, 2009

Here's a project I started last night and finished off today. Thought it'd be fun to make a Minesweeper solver bot! It gets the handle of a current open Minesweeper game and processes based on that. It reads the image of the window, processes the image to work out where the tiles are, feeds that tile data into a MinesweeperBoard, and that board then processes all the tiles that can be worked out, if there's any definite bombs, and any definite safe locations. If there's any of those, it clicks them and continues. If there's none of those, it's forced to choose a random location.

I thought minesweeper didn't have any random elements in it until I made this, and I realised sometimes you just click once and get a single "1" or something, with no way to possibly tell where the bombs are without clicking again in another location, probably clicking a bomb. So the bot keeps restarting until it can find a possible game solvable by humans. It'll try and click somewhere random, but it has just as good a chance as we do to get it right (not very much).

Always sad seeing it fail with only a few tiles left though. It's written in C++ using standard WinAPI functions to get the window handle and SDL to process the image of the board. Works on every board size too, automatically calculates how many tiles.

Anyway enough babble, here's a video!

-snip-

Also that video IS realtime. The click speed is one click every 20ms. Any smaller and windows click handler starts to bug out a little bit.

The saddest part about this is that 50% of the time it took to make it was trying to mess with the stupidly ancient WinAPI functions with cryptic names such as LPCZSTR and such.

Also if anyone's interested here's the process to "solving" the current state of a minesweeper game. I just simplified a typical thought process into steps.

1) Loop over grid and find value cells
2) Loop over value cells, find definite bombs (value cell with a single unknown adjacent cell)
3) Subtract bombs from numbers and mark bombs
4) Find any definite okay positions (at least one adjacent 0)

Jewel fucked around with this message at 05:21 on Dec 6, 2013

# ? Dec 5, 2013 10:23

atmz: Jan 5, 2005; lurk lurk lurk

I've just gotten out of a few years of application development in C++ and I've been trying to keep myself busy and also re-learn webdev, which I haven't really touched for a decade or so. Unfortunately, I'm still using PHP because everything else seems to be a massive pain to set up. I made this as a weekend project last week, it's a location-based anonymous message stream which can be sorted based on proximity or time; it's mostly useless but kinda fun:

I'm currently working on a Markov text generator that allows mashing up of different corpuses (corpi?) with optional color-coding to show where things are coming from. It's fun but slightly pointless (there may be a theme here?). I'm using the two previous words to determine the next, so it's not technically a Markov process but this seems to give (slightly) more readable results.

# ? Dec 5, 2013 11:36

TJChap2840: Sep 24, 2009

Jewel posted:

Cool Minesweeper stuff

I've played a few games where I had two spaces left and the only numbers next to those spaces were '2'. I stopped playing Minecraft at that point. Such a disappointment.

# ? Dec 5, 2013 14:43

Jewel: May 2, 2009

TJChap2840 posted:

I've played a few games where I had two spaces left and the only numbers next to those spaces were '2'. I stopped playing Minecraft at that point. Such a disappointment.

Ahaha I hope this wasn't a subtle joke but if that wasn't on purpose, I almost caught myself typing that all day.

# ? Dec 5, 2013 14:59

Internet Janitor: May 17, 2008; "That isn't the appropriate trash receptacle."

It's worth noting that Minesweeper is NP-Complete.

# ? Dec 5, 2013 15:18

Jewel: May 2, 2009

Internet Janitor posted:

It's worth noting that Minesweeper is NP-Complete.

Ah neat! Yeah the only way to make my algorithm better would be an educated guess when it has no definite moves instead of random. Stuff like not picking a cell near a cluster of numbers and instead pick one furthest away from the most numbers. But even then it's still all completely chance.

# ? Dec 5, 2013 15:30

forelle: Oct 9, 2004; Two fine trout; Nap Ghost

hendersa posted:

Well, I guess there are six parts:

1. Get the start of the voxel pipeline in place within an emulator as a proof of concept.
2. Figure out how to integrate ARToolkit into the emulator for augmented reality support.
3. Establish the shadow memory in the PPU to provide the proper tile metadata for voxel positioning data.
4. Populate the metadata with tile information that makes it all look 3D-ish.
5. Port the whole shot to a BeagleBone Black once TI gets around to getting their OpenGL acceleration working.
6. Document the whole thing and provide a system image with source code for educational purposes.

Also, I put together a quick video: https://www.youtube.com/watch?v=DJKqzBSx3yk

Can you key out the blue sky? I.e. remove the sky it and make it transparent?

That would be awesome as it would reveal the main game play elements in a much nicer way (IMHO)

# ? Dec 5, 2013 18:51

Opinion Haver: Apr 9, 2007

TMZ posted:

I've just gotten out of a few years of application development in C++ and I've been trying to keep myself busy and also re-learn webdev, which I haven't really touched for a decade or so. Unfortunately, I'm still using PHP because everything else seems to be a massive pain to set up.

If you want a guide to setting up webdev with a real language, the person who wrote the canonical 'PHP sucks' article wrote a quick guide on how to make a guestbook in Python.

# ? Dec 5, 2013 19:10

hendersa: Sep 17, 2006

forelle posted:

Can you key out the blue sky? I.e. remove the sky it and make it transparent?

That would be awesome as it would reveal the main game play elements in a much nicer way (IMHO)

Oh, I'll be doing far more than that. The idea is that the metadata for each tile describes the Z position and thickness of the voxel for each pixel that makes up the tile. Those background tiles will have a thickness of 0 for each of their voxels, mean that they won't even be rendered. Think of it like this:

1. That block is 32 pixels "thick".
2. Mario and other sprites are rendered in the middle 16 pixels or so of the block.
3. Pipes, blocks, etc. (the "platforms") are rendered the full 32 pixel width.
4. Background elements that don't have any effect on gameplay have a width of 0.

Right now, all pixels have a thickness of the full 32 pixels, which is why it looks like a block. Once I have figured out the proper metadata, Mario will look like he's made out of voxels, rather than looking like an extruded cross-section. The pipes will be rounded, the goombas will have voxel gradients, etc. Something like this:

# ? Dec 5, 2013 19:50

Scaevolus: Apr 16, 2007

Jewel posted:

Ah neat! Yeah the only way to make my algorithm better would be an educated guess when it has no definite moves instead of random. Stuff like not picking a cell near a cluster of numbers and instead pick one furthest away from the most numbers. But even then it's still all completely chance.

That's a really cool bot. I like how it runs quickly enough to make the video feel accelerated. Your algorithm could probably be more sophisticated-- can it properly handle all these patterns?

I should finish up my Nurikabe solver sometime-- writing good heuristics for NP-complete problems is interesting.

Scaevolus fucked around with this message at 23:15 on Dec 5, 2013

# ? Dec 5, 2013 21:54

Tres Burritos: Sep 3, 2009

hendersa posted:

Oh, I'll be doing far more than that. The idea is that the metadata for each tile describes the Z position and thickness of the voxel for each pixel that makes up the tile. Those background tiles will have a thickness of 0 for each of their voxels, mean that they won't even be rendered. Think of it like this:

1. That block is 32 pixels "thick".
2. Mario and other sprites are rendered in the middle 16 pixels or so of the block.
3. Pipes, blocks, etc. (the "platforms") are rendered the full 32 pixel width.
4. Background elements that don't have any effect on gameplay have a width of 0.

Right now, all pixels have a thickness of the full 32 pixels, which is why it looks like a block. Once I have figured out the proper metadata, Mario will look like he's made out of voxels, rather than looking like an extruded cross-section. The pipes will be rounded, the goombas will have voxel gradients, etc. Something like this:

I will buy a beaglebone just to play with this if when you finish it.

# ? Dec 5, 2013 22:03

Polio Vax Scene: Apr 5, 2009

How are you determining the depth of each voxel? Like how will you make the goomba or pipes appear 'rounded'? I assume you have to hardcode for each pixel.

# ? Dec 5, 2013 22:09

MarsMattel: May 25, 2001; God, I've heard about those cults Ted. People dressing up in black and saying Our Lord's going to come back and save us all.

I can now handle inserting objects with arbitrary rotation into my voxel renderer:

This means I can now model things like a spiral staircase pretty easily. Unfortunately the normals at the edges of the cubes seem to go a bit wonky sometimes, I'm not sure what's causing that.

# ? Dec 6, 2013 01:40

hendersa: Sep 17, 2006

Tres Burritos posted:

I will buy a beaglebone just to play with this if when you finish it.

TI and CircuitCo should be paying me some sort of royalties for their ARM SBC hardware sales. I've received at least 25 mails from people saying that they purchased either a BeagleBoard-xM or the BeagleBone Black for the sole purpose of running BeagleSNES. The BBB I can understand, since that is about $45, but the BB-xM? That thing has a base price of $149! ~~When~~ If I get this thing completed, give it a try and let me know what you think.

Manslaughter posted:

How are you determining the depth of each voxel? Like how will you make the goomba or pipes appear 'rounded'? I assume you have to hardcode for each pixel.

All that depth and position metadata is something that I'm going to have to create by hand. I'll go tile by tile and create some metadata for it, and then do some renders and see how it looks. It will be pretty time consuming, I suspect, but nice, low-brain power work to take a break from other things. Character ROM runs from $0000 to $1FFF, and each tile is 16 bytes in size, so that is a total of 512 tiles. I can cheat on a lot of those, though. Some are pure background and can be zero'd out. You've got all the letters and numbers of the font, and those are all just a uniform thickness. One frame of big Mario's animation is made of 8 tiles. So really, you can get the major ones out of the way and then slap in placeholder metadata for the rest until you get around to finding data that looks good.

Objects won't be "rounded" so much as "made to look as round as possible using cubes".

# ? Dec 6, 2013 02:00

Adbot: ADBOT LOVES YOU

# ? May 9, 2024 05:09

Jewel: May 2, 2009

Scaevolus posted:

That's a really cool bot. I like how it runs quickly enough to make the video feel accelerated. Your algorithm could probably be more sophisticated-- can it properly handle all these patterns?

I should finish up my Nurikabe solver sometime-- writing good heuristics for NP-complete problems is interesting.

Ahah, oh gosh I never knew about this page. So many things I didn't think of. But should I go back to it....

# ? Dec 6, 2013 03:33

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Post screenshots of stuff you're working on!

«‹›203 »