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 »

steckles: Jan 14, 2006

Shalinor posted:

That said, yeah, no idea if you're in one of the hubs where you'd need to be for breaking in.

I'm in Vancouver so there is no shortage of stuff in the game industry nearby. A fair bit of high tech stuff in the area as well, nothing interesting enough to lure me away from my current (non programming) job though.

I've thought of applying at places like Solid Angle and Next Limit, companies that do high end rendering software, but they're way not even remotely nearby. Why must North America be such a wasteland for rendering companies?

# ? Aug 8, 2012 20:45

Adbot: ADBOT LOVES YOU

# ? May 15, 2024 19:59

Scaramouche: Mar 26, 2001; SPACE FACE! SPACE FACE!

Yeah I'm in Vancouver as well and know a lot of game guys, and unfortunately they probably wouldn't be into that. Most game engine render programmers are more concerned with speed than they are fidelity in my experience. Maybe someone like Pixar?

# ? Aug 8, 2012 22:40

SuicideSnowman: Jul 26, 2003

Wrote a simple little algorithm to generate random cave-like areas for a dungeon crawler based game I'm working on. The algorithm uses Cellular Automata.

code:

##############################
##############################
##############################
####........######...#########
###..........####.....########
##...###...............#######
##..######........##......####
##..#######...######.......###
##...###############..##...###
###...#############..####..###
#####..###########..####..####
######..########....###...####
#######..######...........####
#######..#####...###......####
#######..####.....##..###..###
#######...###......##.###...##
########..####.###..#..#....##
########..#########.##.....###
########...########........###
###.####....######.....##..###
##....#.....#####...#####..###
##.........######...######.###
##..#......######.......##..##
##..##.#......####..........##
##.............###...##.....##
###.......###..###..####....##
########.......###..####....##
#########.....###########..###
##############################
##############################

That's just a 30x30 map. I can input any size map I want and it'll generate something similar. Having some issues on larger maps with it generating unconnected rooms but it's still a work in progress. My goal is to eventually read these map files into a graphical engine (#'s are walls, .'s are floors). Playing around with procedural generation is fun. Next I want to write a grid based version for dungeon areas.

# ? Aug 9, 2012 03:02

Dolex: May 5, 2001

steckles posted:

I wrote some thin film interference code for simulating soap bubbles and anti-reflective coatings. Surprisingly, it worked on the first compile. I'm 99% certain the colours are not correct, but usually when I write a new light interaction, the first few versions simply fill the screen with NaNs or sprinkle black dots all over the place.

holy loving poo poo @_@

thanks for the book recommendation!

Dolex fucked around with this message at 03:58 on Aug 9, 2012

# ? Aug 9, 2012 03:46

Trabisnikof: Dec 24, 2005

steckles posted:

I wrote some thin film interference code for simulating soap bubbles and anti-reflective coatings. Surprisingly, it worked on the first compile. I'm 99% certain the colours are not correct, but usually when I write a new light interaction, the first few versions simply fill the screen with NaNs or sprinkle black dots all over the place.

Those lenses are so pretty. Also I have a question, the only part that draws my eye away is the chrome seems somehow too shiny, what is that visual effect I am missing? You seem like the kind of person who would know that.

What was the render time like? I'm sure if you started blogging about it you'd start getting offers on your terms.

# ? Aug 9, 2012 03:50

Lemon King: Oct 4, 2009; im nt posting wif a mark on my head

steckles posted:

I wrote some thin film interference code for simulating soap bubbles and anti-reflective coatings. Surprisingly, it worked on the first compile. I'm 99% certain the colours are not correct, but usually when I write a new light interaction, the first few versions simply fill the screen with NaNs or sprinkle black dots all over the place.

Reading this thread casually and I mistook your render for a real photo.
You could easily make some cash just by licensing that renderer out to users.

# ? Aug 9, 2012 04:58

lord funk: Feb 16, 2004

SuicideSnowman posted:

That's cool - post a huge map. Also, I'm pretty sure you procedurally generated the Halo map Sidewinder.

# ? Aug 9, 2012 14:36

netcat: Apr 29, 2008

SuicideSnowman posted:

Wrote a simple little algorithm to generate random cave-like areas for a dungeon crawler based game I'm working on. The algorithm uses Cellular Automata.

That's just a 30x30 map. I can input any size map I want and it'll generate something similar. Having some issues on larger maps with it generating unconnected rooms but it's still a work in progress. My goal is to eventually read these map files into a graphical engine (#'s are walls, .'s are floors). Playing around with procedural generation is fun. Next I want to write a grid based version for dungeon areas.

How do you plan on handling unconnected rooms? I have a roguelike I am coding a bit on now and then and in my "cavernous" maps I can get tiny unconnected areas which I remove using an incredibly slow method.

# ? Aug 9, 2012 14:46

SuicideSnowman: Jul 26, 2003

lord funk posted:

That's cool - post a huge map. Also, I'm pretty sure you procedurally generated the Halo map Sidewinder.

Here's 100x100. I can only do square sizes right now, but it's a pretty simple fix to allow something like 100x50 or whatever. As you can see with the bigger maps, it tends to create a lot of unconnected areas. This one wasn't too bad, but has a few islands.

netcat posted:

How do you plan on handling unconnected rooms? I have a roguelike I am coding a bit on now and then and in my "cavernous" maps I can get tiny unconnected areas which I remove using an incredibly slow method.

I haven't really thought much about it yet. I'm honestly considering redoing the way that I generate the maps. Instead I may use a more grid like system where I generate square rooms that are already connected and then shape around them to make them more cave like.

# ? Aug 9, 2012 15:57

Red Mike: Jul 11, 2011

netcat posted:

How do you plan on handling unconnected rooms? I have a roguelike I am coding a bit on now and then and in my "cavernous" maps I can get tiny unconnected areas which I remove using an incredibly slow method.

One of the easier methods is floodfilling. Make the generator pick one point in the map and floodfill the walkable area. This means having a set with the initial point and adding to it all its walkable neighbours, then all their walkable neighbours, etc, until you don't add anything during one iteration. Any walkable tiles that aren't in the set should then be set as walls, or alternatively create an algorithm to drill a hole in nearby walls until they're connected to the main cavern.

The problem really comes with choosing the point to go off of, since if you choose one of the small unconnected areas, you ruin the map. In this case, you should randomly pick a small number of points (3-5), then repeat the algorithm for each point, without actually destroying tiles yet. Pick the one with the largest set, continue as before.

If you've implemented A*, there's also a simple way of trying to route iteratively from various points.

Alternatively, choose a different algorithm. Making a predetermined layout and eroding it into a cavern-like shape also works.

You can also generate it from set pieces defined beforehand in info files, like my own algorithm:

# ? Aug 9, 2012 17:37

Shalinor: Jun 10, 2002; _{Can I buy you a rootbeer?}

netcat posted:

How do you plan on handling unconnected rooms? I have a roguelike I am coding a bit on now and then and in my "cavernous" maps I can get tiny unconnected areas which I remove using an incredibly slow method.

One of the simplest ways is by just adjusting your gameplay to make use of unconnected rooms. Look at Spelunky, for instance - despite the time invested, it will still happily generate levels that are all but unsolvable without the ability to modify terrain.

... which Derek Yu solved by just, well, letting you modify terrain. In side-scrolling, that means being able to make platforms up and blast down. In top-down, it's even easier - you just need to be able to mine/knock down walls.

Granted, it isn't always an option. That said, it's worth at least considering. You can have a lot more fun with procedural map generation, if you can remove the requirement that all generated maps be naively solvable/pathable.

# ? Aug 9, 2012 17:43

Ari: Jun 18, 2002; Ask me about who Jewish girls should not marry!

Trabisnikof posted:

Those lenses are so pretty. Also I have a question, the only part that draws my eye away is the chrome seems somehow too shiny, what is that visual effect I am missing? You seem like the kind of person who would know that.

Chrome and lenses are not perfect in real life. There's microscopic scratches and smudges and stuff that can be buffed out, as well as dust that's barely visible with the naked eye, but can skew reflections of things. This is something most people don't think about, but it's definitely a tell when trying to figure out when an image of something shiny is rendered or photographed.

The pink squares and the greenish arcs of the two flares on the complex lens were the tell for me, actually - the shapes reflected from the interior lens should have been a little more skewed based on these microscopic imperfections and smudges, unless the picture was taken in a vacuum in a dust-free clean room, of an object never handled by humans.

Edit: otherwise, that is an impeccable image, absolutely stunning. I just want to make that clear

# ? Aug 9, 2012 17:59

netcat: Apr 29, 2008

Red Mike posted:

One of the easier methods is floodfilling. Make the generator pick one point in the map and floodfill the walkable area. This means having a set with the initial point and adding to it all its walkable neighbours, then all their walkable neighbours, etc, until you don't add anything during one iteration. Any walkable tiles that aren't in the set should then be set as walls, or alternatively create an algorithm to drill a hole in nearby walls until they're connected to the main cavern.

The problem really comes with choosing the point to go off of, since if you choose one of the small unconnected areas, you ruin the map. In this case, you should randomly pick a small number of points (3-5), then repeat the algorithm for each point, without actually destroying tiles yet. Pick the one with the largest set, continue as before.

I'm actually using floodfilling... My problem is probably because I use a kinda bad method of finding the initial point (pick a point at random; floodfill; if the number of filled tiles is smaller than a certain threshold, pick another point at random and floodfill again :v:

)

I've also been thinking about using A* but it has a similar problem of finding the initial point.

# ? Aug 9, 2012 20:02

Red Mike: Jul 11, 2011

netcat posted:

I'm actually using floodfilling... My problem is probably because I use a kinda bad method of finding the initial point (pick a point at random; floodfill; if the number of filled tiles is smaller than a certain threshold, pick another point at random and floodfill again )

I've also been thinking about using A* but it has a similar problem of finding the initial point.

Pick three random points (from the walkable tiles only), run all three. Pick the one which had the largest number of filled tiles, use it.

The best way to use this would be to vary the number of random points with the size of the map. So for a 100x100, you'd choose 3, for 1000x1000, you'd choose 5, up to a reasonably sane number.

Unless your floodfilling takes a really long time for some reason, it shouldn't be a problem.

Red Mike fucked around with this message at 20:16 on Aug 9, 2012

# ? Aug 9, 2012 20:13

netcat: Apr 29, 2008

Red Mike posted:

Pick three random points (from the walkable tiles only), run all three. Pick the one which had the largest number of filled tiles, use it.

The best way to use this would be to vary the number of random points with the size of the map. So for a 100x100, you'd choose 3, for 1000x1000, you'd choose 5, up to a reasonably sane number.

Unless your floodfilling takes a really long time for some reason, it shouldn't be a problem.

I use an iterative floodfill and the maps are only 80x25 in size, so it shouldn't be slow, but I haven't profiled the code. That's a good idea though, I'll try it the next time I feel the urge to do some work on the game, thanks!

# ? Aug 9, 2012 20:27

Van Kraken: Feb 13, 2012

netcat posted:

How do you plan on handling unconnected rooms? I have a roguelike I am coding a bit on now and then and in my "cavernous" maps I can get tiny unconnected areas which I remove using an incredibly slow method.

I thought this problem was neat, so here's my take on flood fill, and it seems to work alright, though it could probably be cleaned up a bit.

Python code:

from numpy import array, copy

def read_map(filename, floor='.'):
	'''Reads a roguelike map from a text file
	# is wall, . is floor
	returns a 2D array with 1 as floor and 0 as wall'''
	cave_map = []
	with open(filename, 'r') as f:
		for line in f:
			cave_map += [[1 if char == floor else 0 for char in line.strip()]]
	return array(cave_map)

def open_neighbors(cave_map, row, col):
	'''Finds all open floors near a chosen floor x,y position
	Floor is assumed to be 1'''
	neighbors = []
	for r in range(max(row - 1, 0), min(row + 1, len(cave_map)) + 1):
		for c in range(max(col - 1, 0), min(col + 1, len(cave_map[0])) + 1):
			if cave_map[r,c] == 1 and not (r == row and c == col):
				neighbors += [(r, c)]
	return neighbors

def keep_largest_subgraph(cave_map):
	'''Returns a copy of the map with only the largest connected
	subgroup remaining'''
	graph = copy(cave_map)
	groups = []
	group_num = 2
	for row in range(len(graph)):
		for col in range(len(graph[0])):
			if graph[row,col] != 1:
				continue
			group_size = 0
			current_group = [(row,col)]
			while len(current_group) > 0:
				group_size += 1
				cur_pos = current_group.pop(0)
				current_group += open_neighbors(graph, *cur_pos)
				graph[cur_pos] = group_num
				for pos in open_neighbors(graph, *cur_pos):
					graph[pos] = group_num
			groups += [(group_size, group_num)]
			group_num += 1
	largest_group = max(groups)[1]
	for row in range(len(graph)):
		for col in range(len(graph[0])):
			graph[row,col] = (1 if graph[row,col] == largest_group else 0)
	return graph

It catches every group, but I'm not sure how well it performs on big maps. Does anyone have a pastebin of a 100x100 or larger map? I have no way of generating them myself.

# ? Aug 9, 2012 20:56

SuicideSnowman: Jul 26, 2003

Van Kraken posted:

I thought this problem was neat, so here's my take on flood fill, and it seems to work alright, though it could probably be cleaned up a bit.

It catches every group, but I'm not sure how well it performs on big maps. Does anyone have a pastebin of a 100x100 or larger map? I have no way of generating them myself.

Pastebin was messing up the output on maps so I couldn't do that, but I uploaded a 500x500 one to SendSpace: http://www.sendspace.com/file/masy8k

SuicideSnowman fucked around with this message at 21:31 on Aug 9, 2012

# ? Aug 9, 2012 21:17

Van Kraken: Feb 13, 2012

SuicideSnowman posted:

Pastebin was messing up the output on maps so I couldn't do that, but I uploaded a 500x500 one to SendSpace: http://www.sendspace.com/file/masy8k

Cool, thanks. It runs in about 2.75 s on this map, so not great. Might be better with a faster language, but I think it's probably my implementation. What are you gonna do? �\_(ツ)_/�

# ? Aug 9, 2012 22:00

SuicideSnowman: Jul 26, 2003

Van Kraken posted:

Cool, thanks. It runs in about 2.75 s on this map, so not great. Might be better with a faster language, but I think it's probably my implementation. What are you gonna do? �\_(ツ)_/�

That's not too bad really and to be fair, I doubt many people are going to want to run through a 500x500 randomly generated map (I could be wrong). I just made it that size to stress your program.

# ? Aug 9, 2012 22:03

Van Kraken: Feb 13, 2012

Ha ha, I replaced the numpy arrays with plain old lists and now it runs in 0.9 seconds. :downs:

# ? Aug 9, 2012 23:20

Chosen: Jul 11, 2002; Vibrates when provoked.

Van Kraken posted:

Ha ha, I replaced the numpy arrays with plain old lists and now it runs in 0.9 seconds.

I think that's because numpy is not so great with individual assignments by coordinate. In the 2011 AI Challenge, I had luck rolling the map in 4 directions and doing logical ANDs to determine boundaries of water (impassable terrain).

# ? Aug 9, 2012 23:50

steckles: Jan 14, 2006

Trabisnikof posted:

Those lenses are so pretty. Also I have a question, the only part that draws my eye away is the chrome seems somehow too shiny, what is that visual effect I am missing? You seem like the kind of person who would know that.

Real materials have scratches on them. Normally you'd use a bump map to add this effect, but I suck at UV mapping, so I didn't bother.

Trabisnikof posted:

What was the render time like? I'm sure if you started blogging about it you'd start getting offers on your terms.

I think the time for this one was about nine hours. This was on three cores of an i5 at 4.4ghz. It's a long time, but that's not too far off from what a commercial renderer like Maxwell will take.

Lemon King posted:

You could easily make some cash just by licensing that renderer out to users.

The thought has crossed my mind, but a renderer is more than just the engine. Interacting with various modelling applications is tough too. Just getting the geometry isn't too hard in most cases, but dealing with materials can annoying. Being physically accurate, the material system in the renderer is quite different than the options available in, say, Blender.

# ? Aug 10, 2012 02:59

Tres Burritos: Sep 3, 2009

Red Mike posted:

One of the easier methods is floodfilling.

Ah gently caress. I decided to try my hand at detecting the 500 by 500 before reading the wikipedia article on flood filling.

Did it recursively in c#. Overflowed my stack.

http://pastebin.com/d2HFbvRb

:downsgun:

And I thought I was being clever. Works on the smaller ones though.

Theory was if you loaded all the initial "floors" and their XY values into a sorted list you could pick any one of the points and it would select all of the connected floors and put them into the same object. Then you could just choose the object with the most floors as your main cave. Also, did some .Contains() instead of .BinarySearch() which I think is a no-no.

Edit: That was pretty fun though.
Edit2: Huzzah, no recursion and you get an output of all the contiguous floor regions in .657 secs on my i5. That's only if you assume the floor regions are already loaded in memory and you don't have to read them from a file. I'm done now.

Tres Burritos fucked around with this message at 05:42 on Aug 10, 2012

# ? Aug 10, 2012 04:34

Van Kraken: Feb 13, 2012

Interesting. It turns out that Scipy has its own function, scipy.ndimage.label, that's exactly the same as a flood fill, and nicely separates the groups by number.

The relevant function now looks like this:

Python code:

from numpy import array, copy, vectorize
from scipy.ndimage import label, histogram

def keep_largest_subgraph(cave_map):
	'''Returns a copy of the map with only the largest connected
	subgroup remaining'''
	s = [[1,1,1],[1,1,1],[1,1,1]] #include diagonal connections
	lmap, count = label(cave_map, structure=s)
	group_sizes = histogram(lmap, 1, count, count)
	largest_group = max(zip(group_sizes, range(count)))[1] + 1
	return vectorize(lambda x,y: int(x==y))(lmap, largest_group)

My whole program now runs in 0.28 seconds, file io included. I guess the relevant lesson is "always check if someone else has done the work for you."

# ? Aug 10, 2012 08:05

Toper Hollyphant: Jul 31, 2010

steckles posted:

I wrote some thin film interference code for simulating soap bubbles and anti-reflective coatings. Surprisingly, it worked on the first compile. I'm 99% certain the colours are not correct, but usually when I write a new light interaction, the first few versions simply fill the screen with NaNs or sprinkle black dots all over the place.

Yeah you're probably the single biggest reason why I don't post here as much as I'd like to. All your work makes everything I make look petty. Also gives me the feeling that I should put more hours on my personal projects. (Which is a good thing)

Anyways, again that's just awesome work, photorealistic indeed.

edit: Didn't plan on making it sound so depressing

It's brilliant to see the amount of great work done by goons in every field. I was just cursing because of the high threshold that creates for me to post. Though I guess that would probably be one way to force myself to put more hours if my projects would be public to others.

Toper Hollyphant fucked around with this message at 23:46 on Aug 10, 2012

# ? Aug 10, 2012 23:18

Trabisnikof: Dec 24, 2005

^So? Post anyway! Everyone is following in the footsteps of giants.

steckles posted:

Real materials have scratches on them. Normally you'd use a bump map to add this effect, but I suck at UV mapping, so I didn't bother.

I think the time for this one was about nine hours. This was on three cores of an i5 at 4.4ghz. It's a long time, but that's not too far off from what a commercial renderer like Maxwell will take.

The thought has crossed my mind, but a renderer is more than just the engine. Interacting with various modelling applications is tough too. Just getting the geometry isn't too hard in most cases, but dealing with materials can annoying. Being physically accurate, the material system in the renderer is quite different than the options available in, say, Blender.

Yeah dude, start a blog and you'll get offers that include being able to work remotely from wherever you currently live. I figured that it was a model issue (on the lens and chrome), I think you under-estimate the number of companies that would kill to be able to integrate your knowledge that into their codebase. But then again, your main job may be Santa Claus, but seriously good work.

# ? Aug 10, 2012 23:30

Tres Burritos: Sep 3, 2009

Van Kraken posted:

My whole program now runs in 0.28 seconds, file io included. I guess the relevant lesson is "always check if someone else has done the work for you."

I could only get it down to .421 seconds with file io.
I concede defeat you bastard. :argh:

# ? Aug 11, 2012 02:59

steckles: Jan 14, 2006

Toper Hollyphant posted:

Yeah you're probably the single biggest reason why I don't post here as much as I'd like to. All your work makes everything I make look petty.

I find this thread to be very inspiring and I would hope the my own posts are inspiring as well, rather than intimidating.

By all means, post. We all have to start somewhere, and I certainly wouldn't have gotten as far as I have with my ray tracer if it weren't for the help of kindly forum posters.

Trabisnikof posted:

Yeah dude, start a blog and you'll get offers that include being able to work remotely from wherever you currently live.

Perhaps, it's probably worth a try!

# ? Aug 11, 2012 09:20

Red Mike: Jul 11, 2011

steckles posted:

I find this thread to be very inspiring and I would hope the my own posts are inspiring as well, rather than intimidating.

By all means, post. We all have to start somewhere, and I certainly wouldn't have gotten as far as I have with my ray tracer if it weren't for the help of kindly forum posters.

They are intimidating, as well as inspiring, for me at least.

I'm probably not the only one, but your last image/post convinced me to give it a go as well. It was quite fun so far.

I also documented my slow journey through learning raytracing. It's quite a small and silly thing, but I'm proud of myself for having managed it in just two days.

# ? Aug 11, 2012 09:54

steckles: Jan 14, 2006

Red Mike posted:

I also documented my slow journey through learning raytracing. It's quite a small and silly thing, but I'm proud of myself for having managed it in just two days.

Good job! Although I wouldn't call your progress slow. It took me a week to get as far as you did when I wrote my first ray tracer.

# ? Aug 11, 2012 20:02

Polio Vax Scene: Apr 5, 2009

Got bored today, made this

# ? Aug 12, 2012 03:17

Nition: Feb 25, 2006; You really want to know?

Reminds me of the old fractal tree generator that came with Encarta.

# ? Aug 13, 2012 05:32

Red Mike: Jul 11, 2011

steckles posted:

Good job! Although I wouldn't call your progress slow. It took me a week to get as far as you did when I wrote my first ray tracer.

Thanks! It feels slow, at least. Took me another whole day to remake it into a better engine and add refraction.

Sadly, this is probably as far as I'll take it, at least for a long while. I'd need to make it triangle-based and find some free assets to work on. Still, a really fun experience.

# ? Aug 13, 2012 19:34

Wedge of Lime: Sep 4, 2003; I lack indie hair superpowers.

For a while now I've been working on developing a tracing library for a user land driver under Linux on an embedded arm device called the Allwinner A10.

Here is a screen shot of the output. Its not especially exciting to look at but quite a lot of work went into it. Especially the instruction parsing and processing.

I've got my code up on github with more details https://github.com/iainb/CedarXWrapper if anyone wants to take a look.

# ? Aug 13, 2012 20:35

hendersa: Sep 17, 2006

Wedge of Lime posted:

For a while now I've been working on developing a tracing library for a user land driver under Linux on an embedded arm device called the Allwinner A10.

Here is a screen shot of the output. Its not especially exciting to look at but quite a lot of work went into it. Especially the instruction parsing and processing.

I've got my code up on github with more details https://github.com/iainb/CedarXWrapper if anyone wants to take a look.

This is a nice piece of work. Simple and clean. I thought you were taking an strace/truss approach to get the libc calls that wrap system calls, but I can see that you've got wrappers in wrap.c to handle those. That would explain why you're showing so few functions in your output... you're only catching ioctl() calls and some memory ops.

I don't usually see opcode cases like you have in instructions.c, though. Your way is very clean and logically grouped, and more intuitive to follow. I usually see a big, honking switch statement for every single interesting opcode/addressing mode combo with a default case at the bottom for whatever opcodes you don't care about. The big switch statement is for speed, since you avoid multiple comparisons on each opcode to whittle down to the special case that you want. That way is all about performance. If it isn't that much of a slow down for you, then your way is much easier to follow.

FYI, I've done much the same thing that you have in the past, except it was for developing/debugging an audio driver in userspace. I would lspci to find the memory space for the PCI device, mmap() /dev/mem in my userspace "driver" to get access to the memory-mapped PCI control registers, mprotect() to make those memory pages writable, and then write straight to those mapped registers to control the hardware

It is SO much easier to catch buffer overflows and other assorted bad behavior in userspace than as a kernel driver, so you're definitely taking a good approach. Thanks for putting it out there for others to learn from.

# ? Aug 13, 2012 21:08

Wedge of Lime: Sep 4, 2003; I lack indie hair superpowers.

hendersa posted:

This is a nice piece of work. Simple and clean. I thought you were taking an strace/truss approach to get the libc calls that wrap system calls, but I can see that you've got wrappers in wrap.c to handle those. That would explain why you're showing so few functions in your output... you're only catching ioctl() calls and some memory ops.

The user land driver doesn't really do much other than memory operations and some ioctls. So without the memory ops you don't really observe anything useful at all.

For example tracing the playback of a tiny 500Kb h264 file produces about 5Mb of output.

hendersa posted:

I don't usually see opcode cases like you have in instructions.c, though. Your way is very clean and logically grouped, and more intuitive to follow. I usually see a big, honking switch statement for every single interesting opcode/addressing mode combo with a default case at the bottom for whatever opcodes you don't care about. The big switch statement is for speed, since you avoid multiple comparisons on each opcode to whittle down to the special case that you want. That way is all about performance. If it isn't that much of a slow down for you, then your way is much easier to follow.

Thanks, I mainly split up the instruction parsing so I could understand what was going on. Parsing the instruction, performing the required operation and recording the result is quite tricky.

Initially I did start with a big switch statement but it became unmanageable, so I decided I'd sacrifice speed for readability. Currently it takes about 60-80ms to decode a small h264 frame while tracing.

# ? Aug 13, 2012 22:24

_Gumby: Sep 14, 2005; Fun Shoe

I wrote this when I was bored over the weekend, it takes netflow/ipfix data, uses a geoip database to determine location of source/destination ip addresses, then draws a nice little visualisation of the data traveling. Its absolutely useless, but the higher-ups at my workplace thought it was super awesome, so that's always nice..

It looks a lot nicer when its animating...

# ? Aug 14, 2012 14:25

syntaxrigger: Jul 7, 2011; Actually you owe me 6! But who's countin?

_Gumby posted:

I wrote this when I was bored over the weekend, it takes netflow/ipfix data, uses a geoip database to determine location of source/destination ip addresses, then draws a nice little visualisation of the data traveling. Its absolutely useless, but the higher-ups at my workplace thought it was super awesome, so that's always nice..

It looks a lot nicer when its animating...

That is really neat! Is the map of the earth generated by the program or is it a static image?

# ? Aug 14, 2012 14:43

INTJ but horny: Feb 3, 2011; AH, YES.
YOU FOUND MY
LAIR'S SECRET
ENTRANCE.

It seems to be the map from DEFCON and everyone's nuking Australia :australia:

# ? Aug 14, 2012 15:14

Adbot: ADBOT LOVES YOU

# ? May 15, 2024 19:59

Clavius: Oct 21, 2007; Howdy!

Some of yall might remember the little zelda-ish JS game engine I posted a while back. Well I kinda spent a ridiculous amount of time rebuilding it from the ground up with a crazy editor and proper zelda 3 graphics and stuff. Here's how the game looks:

GO PLAY WITH IT

It's pretty sweet, it has a few types of collisions, water physics, infinite floor support, jumping off ledges, teleports between locations, etc.

The coolest thing I think is support for an infinite amount of floor layers with a fairly reliable seamless transition method between them so you can walk underneath like ten different layers of graphics and still have everything display properly. I limited it in the editor to four just for clarity and lag reasons, but it could theoretically do as many as you want. I set up a few nice little tests for it in the setup example.

A few things I haven't done (yet?): Diagonal tiles, I did these the last time I wrote an engine but the code has changed so much that and become a shitload more modular, I haven't managed to wrap my head around it. Enemies, interactive objects like heart pieces and rocks and poo poo. Overworld transitions, so like moving between areas with a visual moving transition. Basically stuff I haven't gotten to yet.

I also want to rewrite the way the graphics work. Right now it uses image files like this one to build everything:

I wanted it to be super moddable so that could like, make a graphics set in photoshop and drop it straight in and start moving tiles around. For this type of thing though i've found that the flexibility you get with palettes and so on is better. I'd like to build a thing that takes an image you give it and translates it into usable palletted graphic sets.

The way it works is that you have graphic sets like that one above, then you have tile sets. Tiles are made with four slots for graphics with three potential frames of animation and a set 'behaviour', so wall, floor, water, etc. You drop in one of these tiles in the area editor and the game engine decides what to do based on the behaviour setting of that particular sub-tile. Makes editing areas super easy and fun.

The editor is a whole nother animal that I spent a ridiculous amount of time building, I'll probably write a huge post/guide for that thing in another post. It seems pretty self explanatory to me right now but that's probably because I've been using it as I've built it...

Anyway, play with it, it's rad as heck. Build your own link to the past landscape in a friendly web interface. Right click for context menus. Ctrl and Alt keys for adding to/removing from selections of tiles.

If you want to save something you build in it, click on the "edit game data directly" button in the top right and save the stringed JSON in a text file.

e:
works best and fastest in chrome. One or two things in the editor are broken in FF at the moment, something to do with events. IE support is less than zero in any version for now.

Clavius fucked around with this message at 17:29 on Aug 14, 2012

# ? Aug 14, 2012 17:05

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

«‹›203 »