I recently (5 weeks ago) started my first school year in an school based apprenticeship to become an IT assistant.
We're learning programming and are starting with very basic processing things, while the ultimate plan is to get into C#.
Now I understand that processing might not be the best language for my little project but I still would like to work this out somehow.
What I want to build is a "Stargate Dial Computer". If you know the TV Show you'll know what I'm talking about.
I wanted to make it visually appealing so I decided to use one of the available tools to create my shapes as I am using a DHD (term from the show) for the dial process - see picture: https://i.imgur.com/r7jBjRG.png
This small shape setup already is over 500 lines of code and that seems unwise in itself. Besides that, the plan is to have every single of these trapezoids be a pushable button - but to achieve that manually I'd have to check their coordinates against the mouse collision to utilize them as buttons.
What I'm asking for now is any input on how to work with these shapes in a logical way to make my Idea even possible.
Something like, checking for the shape's color instead of the shape's coordinates itself like 40 times and getting the "active" shape's size in some kind of function. Or a way to just get every shape one by one in a loop, checking for every beginShape and endShape instance if that wouldn't be a performance nightmare.
Keep in mind that I am a beginner. I do know the basics, also of other languages, and I can apply some programming logic here and there - but since I'm not sure what processing can and can't do (yet) I'm looking for an answer to the question if this is even reasonable or possible, or not.
Any help and ideas would be much appreciated!
Thanks!
So, I'm working on a small indie game, and for that I made my own animation system, it's pretty efficent at the moment, but I have some doubts about how it'll operate, after I add 20-30-100 more animations, because (as the title says) every single frame is a different image, in a separated folder.
So the question is: How will this work, after I add more animations? Will it cause longer loadtimes, or worse performance? I'm not totally sure, because eg. the file size of the same animation on a spritesheet and if separated, are almost the same.
The question you should ask yourself when making this sort of decision is "what is the cost of switching if I chose the simpler solution now, and need the complex solution later"?
In this case, switching involves:
Switching your animation system to use the sprite sheet instead of the individual images. This can be really easy if you make your resource fetching and animation calls clean interfaces, and is not too bad unless you do something really horrible in your code.
Getting a program that combines your individual sprites into spritesheets. A quick google search will find dozens of simple programs that do this, but if you need to write your own for some reason it shouldn't be that bad either.
So, my non-answer answer is you probably should not care and if you still care, just take an hour or two and try both.
My basic issue lies in that the images I am drawing will 'flicker', often. My program flow works exactly as I wish apart from this, and is as follows:
Uses G.Clear, to Clear all previous screen instances.
Draws entities/shapes.
Performs functions for positions of next entities, and Restarts the flow.
(This essentially shows a pendulum in motion, which unfortunately flickers strongly.)
I believe the issue lies purely in G.Clear causing the choppiness.
I apologize if this isn't concise enough, and thanks in advance to anyone who can help me out here.
Try switching doublebuffering on.
I'm a little confused on Xlib programming now. I started to use dwm (a lightweight window manager) a few weeks ago, and I'd like to pickup some Xlib programming books or online resource to customize the dwm.
However, after Googling around the web, I don't see much new articles talking about Xlib?? The newest programming guide for X window system on Amazon is in 1994!? Is no new articles of Xlib because the old book are sufficient, or because there are some new technology that I'm not aware of? Or, maybe I didn't have the right keyword to search on the web. If that's the case, can someone please point me to the right place?
There aren't any up-to-date books that I know of. You really just have to read a bunch of specs and source code. Fortunately it isn't that complicated.
I'd say reading the source to gtk+/gdk/x11 (the X backend to GTK) and the source to your favorite couple of WMs would go a long way. The ICCCM and EMWH specs are essential.
A huge change in X programming since the old guides is that nobody likes to use many of the server-side facilities for drawing, fonts, printing, etc. anymore. So XDrawFoo functions, everything about fonts, XPrint, GCs, colormaps, all that is more or less obsolete. Drawing is generally done on the client side now with libraries such as Cairo or Skia.
The stuff about windows and pixmaps and the basic way X works in those old books would still be accurate though.
Some good general X advice if you're messing with a WM:
you need to respond to events rather than getting state. For example, always consider your size to be the last size you got a ConfigureNotify for; don't call XGetGeometry or something to get your size. Getting state has two problems: it kills performance (blocking for a round trip = performance death) and it introduces race conditions.
in a WM, you're dealing with other apps' windows, and they can be destroyed at any time, which will result in an error if you're touching that window. so any function you call on a window may fail.
never use CurrentTime, always use a real timestamp, or you'll create freaky race condition bugs that will drive you crazy
There are lots more tips I guess but those are three to get you started avoiding common mistakes ;-)
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I am planning to give a Technical presentation for a product we are building.
Intended audience is Technical developers. So, most of the time, I will be debugging trough the code in Visual Studio, performance analysis, some architecture review etc.
I have read couple of blogs on font sizes to use, templates to use on Visual Studio, presentation tools, among other very useful tips.
What I am looking specifically for is how to keep the session interesting without making it a dry code walkthrough? How to avoid making people fall asleep? Would be great to hear some stories..
Update1: Nice youtube clip on zoomit. Glue Audience To Your Presentation With Zoomit.
Update2: New post from Scott Hanselman after his PDC talk - Tips for Preparing for a Technical Presentation
Put interesting comments in the code.
// This better not fail during my next presentation, stupid ##$##%$ code.
Don't talk about them, let them be found by the audience.
-Adam
FYI, that Hanselman article has an update (your link is from 2003).
Use stories. Even with code examples, have a backstory: here's why someone is doing this. To increase audience participation, ask for examples of X where X is something you know you can demo, then phrase the walk-through in those terms.
Or maybe you have war stories about how it was different or how it normally takes longer or whatever. I find people identify with such things, then as you give your examples they're mentally tracking it back to their own experience.
I recommend Scott Hanselman's post (previously mentioned). I've written up a post with some tips, mostly for selfish reasons - I review it every time before I give a technical presentation:
Tips for a Technical Presentation
If you're using a console prompt, make sure the font is readable and that your paths are preset when possible.
Take 15 minutes to install and learn to use ZoomIt, so your audience can clearly see what you're showing off. If you have to ask if they can see something, you've already failed.
Probably most important is to have separate Visual Studio settings pre-configured with big, readable fonts.
One of the best pieces of advice I ever got for doing demos is to just plain record them in advance and play back the video, narrating live. Then the unexpected stuff happens in private and you get as many stabs at it as you need.
You still usually need some environment to use as a reference for questions, but for the presentation bit, recording it in advance (and rehearsing your narration over the video) pretty much guarantees you can be at the top of your game.
I also like to put small jokes into the slides and that recorded video that make it seem like the person who made the slides is commenting on the live proceedings or that someone else is actually running the slides. Often, I make absolutely no reference at all to the joke in the slide.
For instance, in my most recent demo presentation, I had a slide with the text "ASP.NET MVC" centered that I was talking over about how I was using the framework. In a smaller font, I had the text "Catchy name, huh?". When I did that demo live, that slide got a chuckle. It's not stand-up worthy by any stretch of the imagination, but we're often presenting some pretty dry stuff and every little bit helps.
Similarly, I've included slides that are just plain snarky comments from the offscreen guy about what I'm planning to say. So, I'll say, "The codebase for this project needed a little help", while the slide behind me said "It was a pile of spaghetti with 3 meatballs, actually" and a plate of spaghetti as the slide background. Again, with no comment from me and just moving on to the next slide as though I didn't even see it actually made it funnier.
That can also be a help if you don't have the best comedic timing by taking the pressure off while still adding some levity.
Anyway, what it really comes down to is that I've been doing most of my demo/presentation work just like I would if it was a screencast and then substituting the live version of me (pausing the video as appropriate if things go off the rails) for the audio when I give it in front of an audience.
Of course, you can then easily make the real presentation available afterward for those who want it.
For the slides, I generally go out of my way to not say the exact words on the screen more often than not.
If you are showing code that was prepared for you then make sure you can get it to work. I know this is an obvious one but I was just at a conference where 4 out of 5 speakers had code issues. Telling me it is 'cool' or even 'really cool' when it doesn't work is a tough sell.
You should read Mark Jason Dominus excellent presentaton on public speaking:
Conference Presentation Judo
The #1 rule for me is: Don't try to show too much.
It's easy to live with a chunk of code for a couple of weeks and think, "Damn, when I show 'em this they are gonna freak out!" Even during your private rehearsals you feel good about things. But once in front of an audience, the complexity of your code is multiplied by the square of the number of audience members. (It becomes exponentially harder to explain code for each audience member added!)
What seemed so simple and direct privately quickly turns into a giant bowl of spaghetti that under pressure even you don't understand. Don't try to show production code (well factored and well partitioned), make simple inline examples that convey your core message.
My rule #1 could be construed, by the cynical, as don't overestimate you audience. As an optimist, I see it as don't overestimate your ability to explain your code!
rp
Since it sounds like you are doing a live presentation, where you will be working with real systems and not just charts (PPT, Impress, whatever) make sure it is all working just before you start. It never fails, if I don't try it just before I start talking, it doesn't work how I expected it to. Especially with demos. (I'm doing one on Tuesday so I can relate.)
The other thing that helps is simply to practice, practice, practice. Especially if you can do it in the exact environment you will be presenting in. That way you get a feel for where you need to be so as not to block the view for your listeners as well as any other technical gotchas there might be with regards to the room setup or systems.
This is something that was explained to me, and I think it is very useful. You may want to consider not going to slide heavy at the beginning. You want to show your listeners something (obviously probably not the code) up front that will keep them on the edge of their seats wanting to learn about how to do what you just showed them.
I've recently started to use Mind Mapping tools for presentations and found that it goes over very well.
http://en.wikipedia.org/wiki/Mind_map
Basically, I find people just zone out the second you start to go into details with a presentation. Conveying the information with a mind map (at least in my experience), provides a much easier way for the information to be conveyed and tied together.
The key is presenting the information in stages (ie, your high-level ideas first, then in more detail, one at a time). The mind-mapping tools basically let you expand your map, as the audience watches and your present more and more detailed information. Doing it this way lets your audience gradually absorb the data in smaller stages, which tends to aid retention.
Check out FreeMind for a free tool to play with. Mind Manager is a paid product, but is much more polished and fluent.
Keep your "visual representation" simple and standard.
If you're on Vista hide your desktop icons and use one of the default wallpapers. Keep your Visual Studio settings (especially toolbars) as standard and "out of the box" as possible. The more customizations you show in your environment the more likely people are going to focus on those rather than your content.
Keep the content on your slides as consisce as possible. Remember, you're speaking to (and in the best scenario, with) your audience so the slides should serve as discussion points. If you want to include more details, put them in the slide notes. This is especially good if you make the slide decks available afterwards.
If someone asks you a question and you don't know the answer, don't be afraid to say you don't know. It's always better than trying to guess at what you think the answer should be.
Also, if you are using Vista be sure to put it in "presentation mode". PowerPoint also has a similar mode, so be sure to use it as well - you have the slide show on one monitor (the projector) and a smaller view of the slide, plus notes and a timer on your laptop monitor.
Have you heard of Pecha-Kucha?
The idea behind Pecha Kucha is to keep
presentations concise, the interest
level up and to have many presenters
sharing their ideas within the course
of one night. Therefore the 20x20
Pecha Kucha format was created: each
presenter is allowed a slideshow of 20
images, each shown for 20 seconds.
This results in a total presentation
time of 6 minutes 40 seconds on a
stage before the next presenter is up
Now, i am not sure if that short duration could be ok for a product demonstration.
But you can try to get some nice ideas from the concept, such as to be concise and keep to the point, effective time, space management etc..
Besides some software like Mind Manager to show your architecture, you make find a screen recorder as a presentation tool to illustrate your technical task. DemoCreator would be something nice to make video of your onscreen activity. And you can add more callout to make the process easier to understand.
If you use slides at all, follow Guy Kawasaki's 10/20/30 rule:
No more than 10 slides
No more than 20 minutes spent on slides
No less than 30 point type on slides
-Adam