That sounds good. I'd be happy to code the mover; it might be nice to set it up so that clicking the mouse creates a mover at that location. An in-game console could also prove quite useful at a later point in time.
Okay, I've split off a whole bunch of view port functions into a separate file, and fixed the scrolling and zooming somewhat. See here. The terrain generation continues to be the main priority. In particular, we need to be able to generate impassable terrain so we can also start to mess with pathfinding.
Anyone, including those not coding, should feel free to test the program and make suggestions. That's something that will always be useful. At the moment, my fork is probably the one you should test. If you like, you can compare the zooming and scrolling to how it was before (issue discussion here), but there's also quite a lot of areas that need suggestions.
However, one of the stated aims of this project is to get as many people to learn to code as possible, so we would like it if you put your best effort into learning. The more you know, the more help you'll be.
while I'm figuring out the github system here, I have one quick suggestion. use: clock = pygame.time.Clock()
while True: clock.tick(30) key = pygame.key.get_pressed() if key[pygame.K_DOWN]: ... updateDisplay() for event... rather than the event.keyDown system. This will allow you to hold a key to scroll, and the clock part and moving the update out of events forces frequent screen updates while scrolling.
I've already added the line pygame.key.set_repeat(800, 20)in order to enable scrolling by holding keys down. It does the job quite well.
Updating should be separate from responding to key presses, but I'm not sure we're quite ready for that yet. For example, I've found that when zoomed out significantly, it can't keep up with the rate of repetition mentioned above (20ms interval = 50 FPS). You can see this visually using the random movers and holding down the spacebar for grid sizes approaching 100x100 or so.
If the framerates are a concern, we may need to make the grid rendering more efficient.
If the framerates are a concern, we may need to make the grid rendering more efficient.
The problem right now is basically that each square is a new surface we are filling, and we are redrawing every surface every time. Obviously we need to implement the basic optimization where we only re-draw the areas of the screen that have changes. Another thing we can do is perhaps use pygame.draw to draw onto a single surface, rather than have a separate surface for each spot on the grid.
In the long run I think the best solution would be to actually render in 2.5D where scrolling and zooming becomes a matter of just moving the camera.
Agreed, although only re-drawing areas that have changes isn't going to help when scrolling and zooming. However, I am sure there are much better approaches than drawing each square separately.
My suggestion to people is to use the Github web site as sparingly as possible. Most of it is useless, distracting, confusing, and will lead you in the wrong direction. Just use the Git command line, and everything will be cool. I will make a helpful guide later.
Yeah, there's a lot you can't do with Windows, but so far on this new laptop it's all I've needed. Still, this laptop has a Core i5-430M, so a VM wouldn't go amiss
Thanks, Andrew. I already split off the view port into a separate ViewPort object in view_port.py, though, so make sure you fetch the latest version and have a look at it. Of course, if you think my ViewPort is terrible feel free to rewrite it
@cheese on last nights comment: Using key.set_repeat looks well enough. As for the clock.tick(frame rate) function only limits frame rates to the number given, the game can/will run slower but never faster. The grid rendering can be made a lot faster by making a single "background" image, and using .draw draw onto it, and if we set it up correctly it'll only redraw where there's change, sprite.RenderUpdates does this pretty handily. If I have the time I can try to code something up for that today.
I've pushed my changes, just waiting for Scott to pull it in. It's quick and dirty, but I thought I would just get it to functional and then people can change their relevant aspects as they see fit.
I was reading cheese's fork, and suddenly, in a moment of revelation, it made absolute and entire sense how it worked. It is time for me to get my shit together, and put in the work learning python.
As for non-coders and coders alike, I think it's a good idea to make a list of what we Need to do, and what we want to do, in order of priority.
I was reading cheese's fork, and suddenly, in a moment of revelation, it madeabsolute and entire sensehow it worked. It is time for me to get my shit together, and put in the work learning python.
Churba, that is so awesome it brought tears to my eyes ^_~
I was reading cheese's fork, and suddenly, in a moment of revelation, it madeabsolute and entire sensehow it worked. It is time for me to get my shit together, and put in the work learning python.
Churba, that is so awesome it brought tears to my eyes ^_~
People making awesome things is awesome, but people making awesome things that make awesome people even more awesome is super-awesome. Careful there, Churba, if you learn to be a good coder you might cause an awesomeness singularity. Still, it could be that Churba's moment of realization was in fact entirely deceptive, and Churba got everything wrong ^_~
One thing I find interesting is that Scott's branch and mine are separate in the GitHub network graph, even though we seem to have the same code at the moment. However, I guess that is the logical result of both of us independently merging Andrew's refactor. Ehehehe, I get to do a pointless empty merge just for fun.
EDIT:
As for non-coders and coders alike, I think it's a good idea to make a list of what we Need to do, and what we want to do, in order of priority.
Careful there, Churba, if you learn to be a good coder you might cause an awesomeness singularity.
Chances are good that I'll be at least decent, I took scrym's advice to learn how the low level shit works before starting to learn. My girlfriend is an absolute magician of a coder(P.s - She lurks this thread, and thinks it's pretty cool. Also, Hey kasha.) and the hackspace crew have been pushing and offering for a while to keep me on the right path, and they're all pretty good. Plus, I can hand my mistakes over to you guys to laugh at and point me in the right direction.
Churba, that is so awesome it brought tears to all three eyes ^_~
Still, it could be that Churba's moment of realisation was in fact entirely deceptive, and Churba got everything wrong ^_~
True that. Only one way to find out - I'm'a learn me some motherfuckin' coding.
Comments
I'd be happy to code the mover; it might be nice to set it up so that clicking the mouse creates a mover at that location.
An in-game console could also prove quite useful at a later point in time.
Edit: The Wikipedia Article isn't helping much.
i.e. the main difference is that it's a permissive license.
The terrain generation continues to be the main priority. In particular, we need to be able to generate impassable terrain so we can also start to mess with pathfinding.
At the moment, my fork is probably the one you should test. If you like, you can compare the zooming and scrolling to how it was before (issue discussion here), but there's also quite a lot of areas that need suggestions.
However, one of the stated aims of this project is to get as many people to learn to code as possible, so we would like it if you put your best effort into learning. The more you know, the more help you'll be.
use:
clock = pygame.time.Clock()
while True:
clock.tick(30)
key = pygame.key.get_pressed()
if key[pygame.K_DOWN]:
...
updateDisplay()
for event...
rather than the event.keyDown system. This will allow you to hold a key to scroll, and the clock part and moving the update out of events forces frequent screen updates while scrolling.
pygame.key.set_repeat(800, 20)in order to enable scrolling by holding keys down. It does the job quite well.Updating should be separate from responding to key presses, but I'm not sure we're quite ready for that yet. For example, I've found that when zoomed out significantly, it can't keep up with the rate of repetition mentioned above (20ms interval = 50 FPS). You can see this visually using the random movers and holding down the spacebar for grid sizes approaching 100x100 or so.
If the framerates are a concern, we may need to make the grid rendering more efficient.
In the long run I think the best solution would be to actually render in 2.5D where scrolling and zooming becomes a matter of just moving the camera.
2.5D would be nice as well.
Edit: Oh wait, I see now. Nevermind then.
No need for Cygwin, and works from the Windows command prompt (though the bundled shell is nice).
This does really justify my need for a new laptop, though. It really struggles anytime the GPU has to turn on.
Still, this laptop has a Core i5-430M, so a VM wouldn't go amiss
The grid rendering can be made a lot faster by making a single "background" image, and using .draw draw onto it, and if we set it up correctly it'll only redraw where there's change, sprite.RenderUpdates does this pretty handily. If I have the time I can try to code something up for that today.
As for non-coders and coders alike, I think it's a good idea to make a list of what we Need to do, and what we want to do, in order of priority.
One thing I find interesting is that Scott's branch and mine are separate in the GitHub network graph, even though we seem to have the same code at the moment. However, I guess that is the logical result of both of us independently merging Andrew's refactor. Ehehehe, I get to do a pointless empty merge just for fun.
EDIT:needs to be repeated.