Bay 12 Games Forum

Please login or register.

Login with username, password and session length
Advanced search  
Pages: 1 ... 17 18 [19] 20 21 ... 23

Author Topic: [PRINT_MODE:SHADER]  (Read 67524 times)

King Mir

  • Bay Watcher
    • View Profile
Re: [PRINT_MODE:SHADER]
« Reply #270 on: June 10, 2012, 08:24:33 pm »

Yeah, good luck with it.

lxnt

  • Bay Watcher
    • View Profile
    • pm:full_graphics
Re: [PRINT_MODE:SHADER]
« Reply #271 on: June 11, 2012, 04:21:24 pm »

In the meanwhile I embedded a python interpeter into the libgraphics.so, modified the lib to run with SDL2, rewrote my old print_mode:shader renderer in python and almost made it all work but for a memory corruption I can't yet trace down. I suspect it has something to do with df executable referencing SDL 1.2 lib. Guess, arrogantly substituting refenced symbols with ones from SDL2 was not going to work after all.

When I'm done with that corruption, it'll be possible to run the fgtesbed both standalone and from inside DF, in a separate window.

The code is here: https://github.com/lxnt/rendumper/tree/fullgraphics.

arclance

  • Bay Watcher
    • View Profile
Re: [PRINT_MODE:SHADER]
« Reply #272 on: July 18, 2012, 02:18:04 pm »

It's been a while since you last posted.
Have you made any progress on the memory corruption problem?
Logged
I think that might be one of the most dwarfen contraptions I've ever seen the blueprints of.
The Bloodwinery v1.3.1 | Dwarven Lamination v1.5 | Tileset Resizer v2.5 - Mac Beta Tester Needed
Sigtext

lxnt

  • Bay Watcher
    • View Profile
    • pm:full_graphics
Re: [PRINT_MODE:SHADER]
« Reply #273 on: July 20, 2012, 03:06:27 pm »

It's been a while since you last posted.
Have you made any progress on the memory corruption problem?

I strongly suspect it is due to sdl12 - sdl20 interaction. Worse yet, disproval of this conjecture would require quite a lot of work. And even if it is not so, having both libraries (and two sets of  dependecies) in the same address space is a recipe for some other disaster.

Instead I decided to "do it right" and split the libgraphics into platform dependent/independent parts, latter to live in dynamically loaded modules. Got burned out while designing renderer interface, so took a month off.

The basic idea is to get rid of any platform-dependent code in the main executable and to make the rendeder live in .dll on win32 while at it. There are five interfaces - musicsound, textures (creature graphics index), keyboard (keybindings, ...), platform (read/write/create/delete files, messageboxes, ...) and the renderer (which isn't finalized yet).

First stage would be a (fully functional, of course) libgraphics.so which instead of containing all the PRINT_MODE and musicsound implementations, will dynamically load them.

After that I hope to persuade Toady to extract whatever code uses the sdl12 calls and is still not in g_src, so that executable itself will not in any way depend on third-party libraries. With some win32-specific glue code and recompilation of the game for win32 using my work, we will at last have means to swap around renderers in win32 too.

I just pushed whatever commits there were, see https://github.com/lxnt/rendumper/tree/interfaces. More work was done, just not committed yet.

The time is ripe :). SDL 2.0 is going to have a release at last, and it seems that Mesa guys will deliver OpenGL 3.0 soon enough for autumn distro releases, so it just might be that my work won't have to rely on dependencies'  bleeding edges.


Edit: committed all pending changes in one lump.
« Last Edit: July 20, 2012, 03:13:36 pm by lxnt »
Logged

arclance

  • Bay Watcher
    • View Profile
Re: [PRINT_MODE:SHADER]
« Reply #274 on: July 20, 2012, 03:27:42 pm »

Sounds promising, though I don't know much about C so the code does not mean much to me at that level.

I understand getting burned out and taking a break.
It reminds me of an assignment we got in the python class I took in college to boost my GPA.

The professor had us use a stripped down version of turtle graphics and told us to program a resizeable snowman using it.
This required that our code draw vector objects which was fine except for the requirement of using circles.
Drawing a circle with turtle graphics is hard because you can't designate individual pixels or draw curves, everything must be done by drawing straight lines at least 2 pixels long.
Several people dropped the class because they could not do it.
I got fed up trying to find a good (i.e. fast) way to do it and instead just did a brute force calculation on every pixel in the canvas to see if it was a part of the circle.

The part that really caused people to get burnt out was that the full version of turtle graphics includes a circle drawing function but we were not allowed to use it.
Logged
I think that might be one of the most dwarfen contraptions I've ever seen the blueprints of.
The Bloodwinery v1.3.1 | Dwarven Lamination v1.5 | Tileset Resizer v2.5 - Mac Beta Tester Needed
Sigtext

lxnt

  • Bay Watcher
    • View Profile
    • pm:full_graphics
Re: [PRINT_MODE:SHADER]
« Reply #275 on: July 20, 2012, 04:51:42 pm »

Might be he thought of drawing a circle with those restrictions as a mathematical programming problem of maximizing a function like f(x,y)=1/(x*x+y*y - r*r) where r is the circle's radius. Might be he did not in fact realize how he was seeing it. It was cruel of him none the less.
« Last Edit: July 20, 2012, 04:57:08 pm by lxnt »
Logged

arclance

  • Bay Watcher
    • View Profile
Re: [PRINT_MODE:SHADER]
« Reply #276 on: July 20, 2012, 05:07:09 pm »

Might be he thought of drawing a circle with those restrictions as a linear programming problem of maximizing a function like f(x,y)=1/(x*x+y*y - r*r) where r is the circle's radius. Might be he did not in fact realize how he was seeing it. It was cruel of him none the less.
I doubt it this was a Programing 101 class, which I was disappointed to find out no longer taught C or C++, which I wanted to learn, but was Python 2.7 instead.
The class was not intended to require math skills on that level, just high school level algebra (passing the "I got a C or worse in high school algebra" math class was the minimum required to take the class) .
We barely covered that type of programing in my 400 level physics classes.

This is my "I don't want to work on this anymore" solution, comments counted towards your grade.
Code: [Select]
def drawCircle(snowMan, circCenterX, circCenterY, radius, lineWidth): # draw a circle with a line width of approximately lineWidth
snowMan.up() # stop drawing
for x in xrange(int(circCenterX - radius - 1),int(circCenterX + radius + 1)): # loop over all pixels in x that the circle could be in
for y in xrange(int(circCenterY - radius - 1),int(circCenterY + radius + 1)): # loop over all pixels in y that the circle could be in
distance = math.sqrt(((x-circCenterX)**2) + ((y-circCenterY)**2)) # find the distance from the circles center to the current x,y position
if int(distance) == radius: # check if the current distance is the radius of the circle
x2 = x+(lineWidth-1) # add linewidth to x point to get second point to draw current outline point
y2 = y+(lineWidth-1) # add linewidth to y point to get second point to draw current outline point
snowMan.move(x,y) # move to current found edge point of circle
snowMan.down() # start drawing
snowMan.move(x2,y2) # move in towards center to draw edge
snowMan.up() # stop drawing
#endif
#endfor
#endfor
#enddef
It's slow enough that you can see it paint the circle on an old computer.
« Last Edit: July 20, 2012, 05:08:45 pm by arclance »
Logged
I think that might be one of the most dwarfen contraptions I've ever seen the blueprints of.
The Bloodwinery v1.3.1 | Dwarven Lamination v1.5 | Tileset Resizer v2.5 - Mac Beta Tester Needed
Sigtext

Lac

  • Bay Watcher
    • View Profile
Re: [PRINT_MODE:SHADER]
« Reply #277 on: July 28, 2012, 08:43:37 am »

Good to hear Windows is back on the cards, albeit with cooperation needed from Toady...which we can pretend might happen!

PS
I thought the convention in Turtle is to draw many-sided polygons to represent circles.  Maybe the tutor didn't expect you to push the number of sides to minimise side length right down to a guaranteed 2px.  Although I'd imagine it is possible to calculate the number sides that would give a side length of 2 for a given radius.   [I found this: side length = 2* radius * sin (PI / num_sides).  I was going to try it on a turtle website, but found it only had arctan and not arcsin, which makes it harder.  But I agree it seems unfair to inflict such maths on a programming course.

Logged

arclance

  • Bay Watcher
    • View Profile
Re: [PRINT_MODE:SHADER]
« Reply #278 on: July 28, 2012, 10:54:54 am »

PS
I thought the convention in Turtle is to draw many-sided polygons to represent circles.  Maybe the tutor didn't expect you to push the number of sides to minimise side length right down to a guaranteed 2px.
My way gets you down to 1px accuracy in the circle but has a minimum line width of 2px because I draw the line from the outside edge towards the center.

Most people cheated and looked up your solution online, I ran out of time to come up with it without cheating so I did it a different way.
The professor did not give us any hints on how to make the circle and most people could not do it on their own.
Logged
I think that might be one of the most dwarfen contraptions I've ever seen the blueprints of.
The Bloodwinery v1.3.1 | Dwarven Lamination v1.5 | Tileset Resizer v2.5 - Mac Beta Tester Needed
Sigtext

lxnt

  • Bay Watcher
    • View Profile
    • pm:full_graphics
Re: [PRINT_MODE:SHADER]
« Reply #279 on: November 16, 2012, 03:46:38 pm »

Today I was surprised to see that my existing code in fact works on open-source amd drivers as of now (ubuntu 12.10, oibaf ppa, kernel 3.7-rc5, hd6850), with minor modifications and quite sad fps.

SDL 2.0 wasn't released yet, though :( 

Seems like the pattern of making a renderer for the previous DF release will continue this time :-/



arclance

  • Bay Watcher
    • View Profile
Re: [PRINT_MODE:SHADER]
« Reply #280 on: November 16, 2012, 04:08:24 pm »

It is good to see that you are still planning to work on it since it has been a while since your last post.
Logged
I think that might be one of the most dwarfen contraptions I've ever seen the blueprints of.
The Bloodwinery v1.3.1 | Dwarven Lamination v1.5 | Tileset Resizer v2.5 - Mac Beta Tester Needed
Sigtext

lxnt

  • Bay Watcher
    • View Profile
    • pm:full_graphics
Re: [PRINT_MODE:SHADER]
« Reply #281 on: November 18, 2012, 03:03:46 pm »

Yeah, feels good to be interested in this again.

I even rewrote the readme file and pushed a dependency-building script.
Other stuff broke though. Open space ceased to be open for example  :P
« Last Edit: November 18, 2012, 03:08:53 pm by lxnt »
Logged

lxnt

  • Bay Watcher
    • View Profile
    • pm:full_graphics
Re: [PRINT_MODE:SHADER]
« Reply #282 on: December 07, 2012, 02:56:58 pm »

First stage would be a (fully functional, of course) libgraphics.so which instead of containing all the PRINT_MODE and musicsound implementations, will dynamically load them.

I have achieved this, sort of.

As of now, I have a  ncurses-mode renderer module, and a stub musicsound module. Plus so-called platform module which implements what's in platform.cpp. And the simulation loop ended up as a separate module too, since it has to be shared between different renderers.

Link is the left part of my sig.

lxnt

  • Bay Watcher
    • View Profile
    • pm:full_graphics
Re: [PRINT_MODE:SHADER]
« Reply #283 on: December 10, 2012, 04:10:09 pm »

That's it.

DF runs in ncurses mode almost without SDL at all.

All platform-dependent code was either moved outside libgraphics.so or converted.

Only the world_graphic-regionN-YYY--XXXXX.bmp generating code is still in the binary itself, and:

 0x00000001 (NEEDED)                     Shared library: [libSDL-1.2.so.0]

 :'(


edit:
Aw, no, I forgot to move out input processing. That and ttf_manager are all that's left to integrate, though ttf_manager would require a graphics-capable renderer to develop with. Well, seems I'll have to revive print_mode:shader for this, meaning GL 2.1 support.

After that there will be experiments on glueing in fgtestbed itself.
« Last Edit: December 10, 2012, 04:36:03 pm by lxnt »
Logged

arclance

  • Bay Watcher
    • View Profile
Re: [PRINT_MODE:SHADER]
« Reply #284 on: December 10, 2012, 04:21:34 pm »

So the only thing left that depends on SDL is some hardcoded part of the worldgen code you can't change?
If so that sounds frustrating.
Logged
I think that might be one of the most dwarfen contraptions I've ever seen the blueprints of.
The Bloodwinery v1.3.1 | Dwarven Lamination v1.5 | Tileset Resizer v2.5 - Mac Beta Tester Needed
Sigtext
Pages: 1 ... 17 18 [19] 20 21 ... 23