Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Overhauling the demo apps

IgnatzIgnatz Mod
in Beta Posts: 5,396

I've suggested to Simeon that we need to completely review the demo apps (which are largely unchanged since 2012), to make them more useful to new starters, and to showcase the great things you can do with Codea.

Simeon has agreed to this.

There is a lot of work involved, but I'm hoping we can take a lot of material from work that has been posted on the forum over the years, and I'm happy to take the lead on the project.

I'm looking for
(a) a couple of volunteers to help me rewrite some of the demo apps and create new apps
(b) people to suggest ideas, comment on the new demos

I realise that many of you are busy, so if at least you can help with (b), that would be good. Also, if you have any projects that might make good demos, please let me know.

I'm thinking of one app per key feature, perhaps with multiple tabs to provide a range of demos from simple to complex. It's important that all the code be explained clearly for new users, to help them try and adapt it for themselves.

I'll wait to hear from you all before going any further, because this needs to be a group effort. I think it is really important in helping new users learn Codea more quickly.

«1

Comments

  • Jmv38Jmv38 Mod
    Posts: 3,295

    i'd be glad to help. I can write small example projects. Maybe you make a public list of every project you need, and we can say 'i pick this one', post the code when done, pick a new one, etc... And if several people propose a project for the same topic, you just choose the one you like best.

  • Posts: 2,020

    Great idea. I think it'd be useful to have a mixture of very simple ones that just illustrate a single concept/ technique (I like the existing multitouch one, just a very simple illustration of tracking touches by indexing a table by touch.id), with more complex ones that join up several concepts.

    The other thing which also struck me as a missed opportunity, is that Codea ships with nice freeware asset packs, some of which aren't used at all in the demos (ie the Tyrian remastered one). It'd be nice to have some kind of old school top-down blaster demonstrating those asset packs (happy to oblige!)

    It would probably also be a good idea to open source everything as they're being developed so that people can chip in with suggestions.

  • IgnatzIgnatz Mod
    edited September 2015 Posts: 5,396

    @Jmv38, thanks for the offer.

    I've made a list of current apps and suggested some broad categories and specific apps in this publicly editable Google document. It's still very rough, so don't get too upset about anything in there!

    https://drive.google.com/open?id=1ZehDMYEK9bBTtlXoBxMb_tA8cSGBa5fr65381ueNb7k

    @yojimbo2000 - this is very much open source, but I think to prevent anarchy and random edits, one person should look after each app, and any issues should be put to a vote of this group (including Simeon of course). That's about as much bureaucracy as we need, I hope.

    I agree with having some simple apps, eg I often look at the animation demo to copy one of the tweens. However, to avoid clutter, I also see value in combining some of those together into one project with several tabs - eg the iPad sensors - camera, Gravity, Gps and tilt could be packaged together. Also special effects such as blend (that one has your name on it, Jmv!), animation, line effects could go together. Maybe Simeon can also group the demo apps into a few categories for users, too.

    But let's discuss.

    (I should just add that although I offered to take the lead, I'm not looking for any kind of control over the project. I just want to make sure it happens, so that new users have an easier transition to our little playground. I also have more time than most, being retired).

  • IgnatzIgnatz Mod
    Posts: 5,396

    With regard to coding styles, I personally am happy to leave it to individual taste, within reason, subject to just one condition - each app must be made as easy as possible for the target user (beginner, intermediate or advanced) to follow and adapt, and be adequately documented. There should be no black box code except perhaps in the "wow" apps we provide to showcase the full potential of Codea (the rollercoaster comes to mind here).

  • Posts: 2,020

    Yes I agree about one person having write privileges for each app. I was thinking of the GitHub model of social coding. So if you would like to suggest changes to an app, you fork it (ie make an independent copy of the code in your own account), make the changes you think are needed, check they work etc, then issue a pull request back on the origin's GitHub page (ie a request to have your changes incorporated back into the origin). This opens up a discussion thread where people can see the changes that are being proposed, try them out, discuss the pros and cons of the changes etc. Ultimately it's just the person with write privileges who chooses whether to accept or reject the changes.

  • IgnatzIgnatz Mod
    Posts: 5,396

    Well, that sounds good. I'll be delighted if we get enough participation to get that happening!

    I'd like to get started straight away, if possible. I've listed a number of possible apps in the Google document above. If anyone wants to have a go at any of them, or has comments or suggestions, please step forward!

  • Jmv38Jmv38 Mod
    edited September 2015 Posts: 3,295

    @Ignatz i'll be glad to pick the 'blending' how-to, as you suggest it.
    If you remember my workbench project, what would you like me to improve? I could clean up the code and add the various 'useful examples list' i posted separately on the forum. Is it what you'd want?
    I also made a project long ago about browsing into unicode characters, i use it regularly to find out in-device images. Would you like this project too?
    I also made a post about 'patterns' explaining step-by-step some patterns. That could be usefull for a beginner, i could put it into a project. What do you think?

  • Jmv38Jmv38 Mod
    edited September 2015 Posts: 3,295

    Would it be allowed to have some very simple tabs in the project, as beginners examples, but wrap the project with a complex interface (i think about using Yojimbo's) all into a single big tab? So we can use nice lists and buttons to browse into the contained examples? We could alernatively make a dependency to Yojimbo' UI project, but i dont like dependencies inside examples.

  • IgnatzIgnatz Mod
    Posts: 5,396

    All of that sounds good to me. We can use as many good apps as possible. Why not start with one of them, and share it when you are ready for feedback?

    With your question about what you should include, I suggest you try to remember what it was like to be a new user, and think about what will be most useful (and/or fun) for them.

    For example, you might start with a really simple demo, and then go on to more detailed examples.

    It's also useful to provide a quick reference for things like blend, eg if you want to look up which blend adds to the colour. You did a nice job of that in your recent demo. For example, you could include a list of different blend types and what they do, as a set of comments.

    But it's up to you to imagine what works best (and have some fun doing it, otherwise you won't want to do any more of them!).

  • IgnatzIgnatz Mod
    Posts: 5,396

    @Jmv38 - yes, I'd definitely like to be able to offer multi tab projects, because that allows us to add layers of complexity gradually, as well as allowing for a range of programming experience.

    Do you remember the code that was developed on the forum a year or more ago, that did this? It has the advantage that each tab's code is completely self contained, requiring just one special line of code at the top, and you can copy and paste the code into your own project, and it will run.

    I will send you a template of this code soon, and share it for others who want to use it.

  • IgnatzIgnatz Mod
    edited September 2015 Posts: 5,396

    @Jmv38 - try using this template for multi tab projects, see what you think. Instructions are in the left hand tab.

    Note - it is a multi tab project, so use a long press.

    http://bit.ly/1QviFN2

  • Jmv38Jmv38 Mod
    edited September 2015 Posts: 3,295

    i see the principle, but i find the code above unecessarily complex... Here is below a much simpler template that does (i think) the same but is even simpler for the user:


    --# demo1 function setup() end function draw() background(153, 192, 208, 255) sprite("Planet Cute:Character Boy",WIDTH/2,HEIGHT/2,300) end --# demo2 function setup() end function draw() background(153, 192, 208, 255) sprite("Planet Cute:Character Cat Girl",WIDTH/2,HEIGHT/2,300) end --# Main -- multitab -- Use this function to perform your initial setup function setup() parameter.action("copy code",function() pasteboard.text = readProjectTab(currentTab) print("done!") end ) button("demo1") button("demo2") runTab("demo1")() end function runTab(name) currentTab = name return function() loadstring(readProjectTab(name))() end end function button(name) parameter.action(name, runTab(name)) end

    Would it be ok to use it?

  • @Jmv38 It doesn't do the same, it leaks globals. If you define stuff in demo1 which isn't overwritten in demo2, they'll still be there in demo2. The point of the code Ignatz posted was to sandbox each tab so that there is no interaction whatsoever.

  • Jmv38Jmv38 Mod
    edited September 2015 Posts: 3,295

    @LoopSpace i see... thanks for pointing that out.
    That kind of 'perfect decoupling' is quite important is real projects with lots of complexity and global, but maybe it is not needed in the current context of 'let's make some simple demos for beginners'?
    It's faily easy for the demo author to avoid problems due to globals leaking... At least i can manage that in my demos.

  • Posts: 2,020

    Or what about just a comment telling the user to move the tab they want to run to the far right (now that the demo projects can be modified without needing to duplicate them)? Wouldn't require additional sand boxing code, would solve the globals problem, and would be a good way of showing new users the importance of tab order too. If I'm running tests in a project, this is usually the method I use.

    Although the sandboxing code is incredibly clever, I worry that it breaks the "black box" rule (it actually says "ignore this code"), and represents something I would only ever use for the purpose of creating a tutorial, not something I'd use in everyday coding projects, say, for creating tests in a project. I know that we're telling users to ignore it (it's meta-code in a sense), I'm just not convinced this is a pedagogically good approach.

    Why not use this is an opportunity to teach a (very) simple way of managing states, as this is something that all but the smallest projects require?

    Eg

    --# Main
    function setup()
      currentState = test1
      currentState.init()
    end
    
    function draw()
      currentState.draw()
    end
    
    --etc
    
    --# test1
    test1 = {}
    
    function test1.init()
    
    end
    
    function test1.draw()
    
    end
    
    --etc
    

    I don't think that the leaking globals issue is that big an issue. Just make sure globals are defined within a function (ie at runtime, not compile time), then you won't get interference between the different states.

    I can see that for some projects, gradually building it up step-by-step would be really instructive. For other projects, an alternative, equally useful approach would be to have sets of tests in each of the tabs (regardless of which approach is used, sandboxing, state management, or just slide the tab to the far right).

  • Jmv38Jmv38 Mod
    edited September 2015 Posts: 3,295

    When i was a beginner, it was clearly 'the simpler, the better', so 'i'll stick to my simple template above, without adding scary clever lines. You can always rewrap it the way you want later, that is ok for me, i wont sue you ;-)

  • dave1707dave1707 Mod
    Posts: 8,396

    I don't think it's necessary to do things this way or that way. Everyone will eventually write code that's comfortable for them. A lot of the newbies don't know anything about coding. They buy Codea thinking they can write some super game to put on the App Store and make a lot of money. They don't know the purpose of setup, draw, or touch. They print information instead of using text. To start, there should be a lot of simple programs that show different for loops, different tables, touches, etc. They should be taught the importance of indentation. Even though I've been using Codea for over 3 years, I don't write code that use different tabs, or dependencies, because I don't write large programs. But that will eventually be important to some of the coders. When I started to learn new languages, I liked to see simple examples that showed exactly what I wanted to do. Once I understood that, I was able to build on that code. So, should we start with a lot of simple code that shows specific commands, or medium programs that show a lot of thing but might be too confusing for a beginner.

  • Posts: 2,042

    Personally, when I started, the Lua Jump example was what got me into it. I wanted to make my own doodle jump, and the Lua Jump example was easy to tweak and play with and make my own.

    My point is, I think any examples we make should be easily scalable and editable. (using variables that are clearly marked, using classes, etc.)

  • @yojimbo2000

    would solve the globals problem

    No it wouldn't. Globals defined in an earlier tab would still be available to a later tab.

    The real issue with these is not with global variables but global functions. There are some special Codea functions that it calls at various times. If, for example, an early tab defines orientationChanged and no later tab overwrites it, then that first definition will stand and be invoked if the user turns the iPad.

    I'm not, though, proposing that this system should be used. I'm not convinced as to the use of such stepped demos in the examples projects, and I agree that the localisation code might be a bit scary.

    I'm not sure what I could contribute to this project. I guess that if there's any code of mine that is deemed suitable for inclusion then I'd be happy to comment it. Will all the existing projects stay, or will there be a cull? If so, that might be something to decide first.

    Though, after looking at Ignatz' document, I think I'd like veto rights on the Quaternion example!

  • IgnatzIgnatz Mod
    Posts: 5,396

    I also have reservations about black box code, and managing it does use up a lot of the debug area at left - but it does make copying and pasting so easy.

    Another way to handle multiple tabs is to use block comment tags to comment out all the code in all the tabs except the one on the left. Then to use one of the other tabs, the user only has to delete one ] at the top. A little clumsy, I know, but probably as simple as sliding tabs around.

    @dave1707, the reason for multiple tabs, is that for say, meshes, it is a good idea to start very simply and work up. If you have a series of separate projects labelled Mesh1, Mesh2, etc, and you do this for each major feature, I leave it to you to figure out how horribly long the eventual list of apps will be. Unless Simeon can put groups of apps in "sub folders" to keep it clean.

    @loopspace - you haven't even seen my quaternion demo yet, you never know, you might learn something [ducks hastily] :D . It may be a bridge too far, and certainly not a priority, but I thought I'd put them on the list initially, because quaternions are so useful for flying apps. Let's do all the important demos first, though.

  • dave1707dave1707 Mod
    Posts: 8,396

    @Ignatz I think I understand what you're saying about tabs now. Each tab would be an increasing complexity of the code.

  • IgnatzIgnatz Mod
    Posts: 5,396

    That's right.

    I call them "step by step" projects.

    But I think we should try to be consistent in how we handle multiple tabs.

  • Posts: 2,020

    Also on the subject of unused assets, I think there should be example programs using the built-in shaders (just very simple ones), as it's not necessarily clear to the beginner, just from looking at the bindings tab in the shader lab, how to actually incorporate the shader into code.

    Looking through the forums, you can often find example code that does this. There are wrappers for the arc shader and the Mandelbrot shader for instance. Perhaps these could be collated into a single shader lab project?

  • IgnatzIgnatz Mod
    edited September 2015 Posts: 5,396

    Yes, I think it would be a good idea to have a library of useful shaders in different tabs of a single project to facilitate copying (I wouldn't include mandelbrot though, I don't see any use for that except in a mandelbrot program).

    Here is my step by step shader project, which keeps things pretty simple

  • A really useful shader would be a tile map shader that takes something like a tiled output and then renders it on a single rect - that would really make a big difference to rendering on platform games.

  • Actually I was thinking more like this - http://blog.tojicode.com/2012/07/sprite-tile-maps-on-gpu.html

    Your shader is great but it just replicates the image across the quad, the link above actually takes a full map and renders that.

  • IgnatzIgnatz Mod
    Posts: 5,396

    It can certainly be done, but I'm not sure it's going to be faster

  • Posts: 2,020

    @TechDojo that's an interesting idea and certainly possible in Codea, but I wonder whether it's faster than a conventional texture atlas approach, ie all background sprites in one texture, the entire background as a bunch of rects on one mesh. Sure, the conventional method has a lot more geometry (but still not enough to really slow things down, eg a screenful of tiles would be 16 * 12 * 6 = 1152 verts), but this method has more complex fragments (2 texture samples in each fragment). I'd be interested in seeing the 2 approaches profiled side by side.

  • Jmv38Jmv38 Mod
    edited September 2015 Posts: 3,295

    Hello! Here is my proposal of blenmode tutorial.

    code: https://gist.github.com/anonymous/c44e36b27c5e85066edd.
    [edit] use this link instead:
    https://gist.github.com/anonymous/dd8a65d353a679e53bf1
    (i introduced a nicer slider to switch between slides).
    [edit] i've noted some inconsitancies in the notations between slides, i'll correct that.
    [edit] version with nice sensor class https://gist.github.com/anonymous/42e8b083a70bd36a1f2a

  • IgnatzIgnatz Mod
    Posts: 5,396

    Cool, thank you. I'll have a look at it.

  • IgnatzIgnatz Mod
    edited September 2015 Posts: 5,396

    @Jmv38 - that is a totally awesome tutorial with so much extra goodness! A new way of doing multi tab projects (with individual tabs which can be copied easily into new projects), and swipe transitions, and drop down selectors on your last demo, too!

    :-O

    I suggest you add a brief description for each demo to the text in the slider bar at the right, i.e. instead of "Demo01", say "Demo01: normal color blending", so if someone comes looking for something specific, they don't have to flick through all the demos to find it.

    A few typos to correct:

    Demo01 - "independent" not "independant", and "default" not "defaut"

    Demo06 - "overlapping" not "overlaping"

    Demo10 - "subtracting" not substracting", "green" not "geen"

    Demo12 - overlapping again

    Demo17 - "subtractive" not "substractive"

    What an amazing effort, well done! You have set a very high standard with that demo.

    ^:)^

  • IgnatzIgnatz Mod
    Posts: 5,396

    I've created a page to hold new demo apps, in the wiki

    https://bitbucket.org/TwoLivesLeft/core/wiki/Codea Demo Apps

    (by the way, it's not just about demos, it's about apps that show what Codea can do as well).

  • Jmv38Jmv38 Mod
    edited September 2015 Posts: 3,295

    @Ignatz i'm quite pleased you liked it that much! Thanks.
    I agree with your suggestions (i thought the same about the slider, but it needs some architecture choices to implement that, so i procrastinated...), and i'll post a corrected version.

  • IgnatzIgnatz Mod
    Posts: 5,396

    Otherwise maybe just print a list of demos in the output area at the left

  • Jmv38Jmv38 Mod
    edited September 2015 Posts: 3,295

    it's ok i finally just changed the tab names, they can be named anything.
    latest version [edit] https://gist.github.com/anonymous/352a8fef0dee0814cee9

  • IgnatzIgnatz Mod
    edited September 2015 Posts: 5,396

    Here is my first attempt at a more detailed mesh demo, something I think is badly needed.

    It's unfinished, but I thought I'd share it to see what you think so far. It's aimed at users who can use sprites and want to go to the next step of using meshes.

    Is it pitched at the right level? Is the pace ok? Is it clear? What suggestions do you have for further steps?

    Note I am using the same method used by @Jmv38 in the demo he posted above. It is very compact, and allows you to set up complete demos in separate tabs in any order you like, and the Main tab just handles them. It's a great way of building step by step demos, and all you need to start using it yourself, is the Main code, which you should always put on the extreme right.

  • Jmv38Jmv38 Mod
    edited September 2015 Posts: 3,295

    it looks good. I would introduce setRect() function to make rectangles, though.

  • IgnatzIgnatz Mod
    Posts: 5,396

    Yes, that's my next step, thank you

  • IgnatzIgnatz Mod
    Posts: 5,396

    I've finished my attempt at meshes, and also a basic physics demo, which are on the wiki page I made earlier, here

    https://bitbucket.org/TwoLivesLeft/core/wiki/Codea Demo Apps

    I think we should keep the previous physics demo as an "advanced" version, because it does joints etc, whereas mine is much more simple.

    It is really hard making these demos, and I think rather than try for perfection, we should just focus on improving the existing apps as much as we realistically can, especially the apps that are of little help to new users at the moment.

    Comments and suggestions (and assistance!?) welcome.

  • Jmv38Jmv38 Mod
    Posts: 3,295

    nice demos, quite useful processes.
    I miss the 'swipe for next slide' though, ;-)

  • IgnatzIgnatz Mod
    edited September 2015 Posts: 5,396

    Nice as your swipes are, some of the demos need swipes, you know :D

  • edited September 2015 Posts: 2,020

    Cool, the meshes demo seems very nice. Are you planning a separate 3D demo?

    Also, is it possible to suggest additions to the built-in assets? ie it might be nice to have some simple tileable textures for demonstrating 3D (tho obviously this depends on licensing, and not adding too much to the install size).

    It also might be nice to include some 3D assets, like some simple .obj models. Currently the asset pickers and readText only see files with extension .txt, but you can open text based files in Dropbox/, Documents/ etc with any extension using os.path io.open and file.read. Or, we could ask @Simeon whether the asset picker and readText commands can be tweaked to see files with different extensions (.obj .mtl etc)

  • IgnatzIgnatz Mod
    Posts: 5,396

    @yojimbo2000 - I'm definitely planning a 3D demo, it is badly needed, also other advanced topics like lighting, terrain etc. Anyone who wants to help is welcome, there is plenty of work to do still.

    However, while I'm keen to add some demos at the advanced end, I'm torn by the realization that there's also a lot to do at the basic level. We really need a "your first app" project which introduces the basics, there is no demo on sockets, there are no Lua demos (eg to explain tables and classes), etc.

    I like the idea of extending assets. There are some free to use tile sheets that would help people do simple animations, too. If we include obj files, then we need to put an obj reader up to Simeon. I'm not sure if mine is robust enough, but I think you have improved on it.

    So (if you have time), why not have a look at this area and put up some ideas?

  • Posts: 2,020

    No problem, I'll see if I can get my version of the obj reader into a presentable state.

  • IgnatzIgnatz Mod
    edited September 2015 Posts: 5,396

    I've added a demo app for 3D lighting to the list

    https://bitbucket.org/TwoLivesLeft/core/wiki/Codea Demo Apps

  • Posts: 2,020

    Speaking of tilesets, the lostgarden guy who did the space cute sprites that currently ship with Codea also has some very nice, slightly retro tilesets on his website (forced perspective not-quite-topdown backgrounds, eg for an RPG), also free to use:

    http://www.lostgarden.com/2006/07/more-free-game-graphics.html

    They're in .bmp format, and are oddly spaced out with lots of blank spaces between tiles (not sure why), and there's lots of superfluous stuff like mask images. So if these were to be included they'd need a bit of wrangling into something more appropriate for Codea (perhaps a .png would be best, for the tiles with transparency? Although pngs seem to take up more space than jpegs).

    It would also be nice to have a tileset with some animation.

  • IgnatzIgnatz Mod
    Posts: 5,396

    I found some animation tile sets a while back, I'll see if I can find them again

  • Jmv38Jmv38 Mod
    Posts: 3,295

    what about this for currentTouch demo:


    --# Main -- CurrentTouch demo00 function setup() info = [[ CurrentTouch gives information on the most recent touch that occurred CurrentTouch.state can have the following values: BEGAN, MOVING, ENDED, CANCELLED The finger position is CurrentTouch.x CurrentTouch.y The last position of this finger is CurrentTouch.prevX CurrentTouch.prevY The difference current position minus last one is CurrentTouch.deltaX CurrentTouch.deltaY If you tap on the screen without moving the finger too much, you get this count: CurrentTouch.tapCount CurrentTouch is always available, but is updated only when you start or move or end a touch Before any touch has occured, it is in CANCELLED state It has a defined id field, but its value is always 0 It is ok with 1 touch only, but it gets messy if you put 2 or more fingers on the screen ]] end -- a table to convert touch state (0,1,...) into a readable string local states = {} states[BEGAN] = "BEGAN" states[MOVING] = "MOVING" states[ENDED] = "ENDED" states[CANCELLED] = "CANCELLED" -- returns a string with all touch fields function touchToString(name,t) local str = { name, "id = ", "state = ", "x = ", "y = ", "deltaX = ", "deltaY = ", "prevX = ", "prevY = ", "tapCount = ", } if t then str = { "", tostring(CurrentTouch.id), states[CurrentTouch.state], tostring(CurrentTouch.x), tostring(CurrentTouch.y), tostring(CurrentTouch.deltaX), tostring(CurrentTouch.deltaY), tostring(CurrentTouch.prevX), tostring(CurrentTouch.prevY), tostring(CurrentTouch.tapCount), } end str = table.concat(str,"\n") return str end function drawTouchInfo(name,touch,x,y) -- draw the touch info fill(57, 57, 57, 255) -- set color for text fontSize(20) -- set font size font("ArialMT") textMode(CORNER) textAlign(RIGHT) -- align text to the left titles = touchToString(name) text(titles,x-10-(textSize(titles)),y) -- draw text on screen textAlign(LEFT) -- align text to the right values = touchToString(name,touch) text(values,x,y) -- draw text on screen end function draw() noStroke() background(178, 178, 178, 255) -- draw the touch local t = CurrentTouch -- a copy fill(255, 190, 0, 255) -- button color ellipseMode(RADIUS) ellipse(t.x,t.y,50) -- draw the CurrentTouch info drawTouchInfo("CurrentTouch : ", CurrentTouch, WIDTH/2, HEIGHT-250) textMode(CENTER) fontSize(17) font("Arial-ItalicMT") text(info, WIDTH/2, 250) end
  • IgnatzIgnatz Mod
    Posts: 5,396

    looks good. =D>

    Can you put it in a gist and give me a link?

Sign In or Register to comment.