Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[King Mir]

Yeah, good luck with it.

[lxnt]

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]

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

[lxnt]

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.

[arclance]

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.

[lxnt]

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.

[arclance]

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.

[Lac]

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.

[arclance]

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.

[lxnt]

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]

It is good to see that you are still planning to work on it since it has been a while since your last post.

[lxnt]

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 

[lxnt]

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]

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.

[arclance]

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.