Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 13 May 2001
Offline Last Active Apr 24 2016 11:53 PM

Posts I've Made

In Topic: How to encode h264 video

11 August 2015 - 08:24 PM

This stackoverflow thread seems fairly straightforward:

1. Configure h264.
2. Alloc a picture.
3. Convert frame from RGB to YUV.
4. Send YUV frame to h264.
5. ...
6. Profit!


I did exactly this using what is now libav for MPEG/H.264 encoding 5+ years ago. What encoder are you using, @amtri, x264?

In Topic: Create polyline with triangles

11 August 2015 - 08:03 PM


 it is possibly that i write it incorrect and you can't understand me. Here I created image showing what i trying to do:



I got red dots as polyline points. It is easy to create line through this dots. But i need to create polyline with width so I need to create it using triangles.But when i directly create it using only right vector i got errors on curves. Is there any algoritmic way to find vertex points for green triangles?


Ah, I see what you mean. Is this a 2D strip or a full 3D "tube"? I'll tackle the 2D solution now, and then we can extrapolate to 3D as necessary.


The key is that the red points define a line through the center of your strip, and that at each joint the red point is the center of a cross-cutting line whose adjacent angle is precisely half the deflection between the segments. So, starting from the left of your diagram and numbering the red points p1, p2, p3 and p4:

  • at p1 there is no previous segment, so our strip's ends are perpendicular to the vector <p2 - p1>;
  • at p2 the cross section is at an angle relative to <p2 - p1> that is precisely half the angle between <p2 - p1> and <p2 - p3>;
  • at p3 we have no next segment, so our strip's ends are again perpendicular to the vector, this tome <p3 - p2>.

Remember that perpendicular lines have slopes that are the negatives of each other.


Using the above, you should be able to generate the points in your strip. Be careful in your algorithm to maintain the correct vertex order. I'll check back in a couple of days to see how you made out.

In Topic: Pygame - time and movement issues

08 August 2015 - 03:20 PM

Unfortunately I can't run your demo because PyGame on OS X relies on X11, which I won't install, and my Linux box is temporarily out of commission. Nevertheless, I know what your problem is.

I've been trying very hard to get smooth movement using Pygame, but no matter how I try, things always look a bit jiggly.
I've read many tutorials about time step and pygame's time module, but it did not help. I would basically like to create pixely, "NES-ish" games and have therefore chosen a fixed time step of about 16 ms (= ca. 60 FPS). I've written a little demo program to test the main loop and see if it runs smooth, but the movement seems to stutter a bit sometimes.


In your main loop, you do two things. You update the player position:

        player_pos[0] += player_speed
        player_rect.center = player_pos

and you update the frame time, setting an upper bound on refresh frequency:

        frame_duration = clock.tick(FPS) # 1 frame -> ca. 16 milsecs

The former assumes that frame_duration is constant, so it uses a constant increment for player position. The latter obtains the actual duration of the frame, which the PyGame docs tell us: "Note that this function uses SDL_Delay function which is not accurate on every platform…"


Your problem is that you are applying what you think is a constant displacement per constant time, yielding constant velocity, but in actuality your time is variable, making your velocity variable. To smooth it out, normalize your displacement by your actual frame time:

FPS = 60
player_speed = 0.8 # pixels per frame
basis_frame_time = 1.0 / FPS

while 1:
    # ...
    frame_duration = clock.tick(FPS)
    frame_displacement = player_speed * (frame_duration / basis_frame_time)
    player_pos[0] += frame_displacement

That should do it.

In Topic: The new 'Disallowed topics' rule

07 August 2015 - 07:54 PM

…I think that ultimately the fate of these causes won't be decided in the next short while here, so a temporary suspension is far from the end of the world.


The fate of these causes is never "decided," anywhere. Change is individual, aggregated. That's why discussion about them is so important: because it's the vector for that individual change.





The rules are the rules. I shall abide them.

In Topic: Python Keyword Arguments for Config files?

07 August 2015 - 07:47 PM

I am really wondering why a solution like this wasn't mentioned on stack overflow.

Isn't that what is the accepted answer here?


Is it a bad idea? It seems like it would work nicely. It seems either they use dictionaries or they get complex.

Yours is a dictionary wrapped in a function, isn't it? If you're writing configuration purely for a Python program, why not make Python itself the configuration language? It's only worthwhile to invest in a different configuration format if you have to share it with other environments.