Jump to content

Flexman

Members
  • Posts

    916
  • Joined

  • Last visited

Posts posted by Flexman

  1. You either love your work or you don't. If people walk out it's either because they wanted an excuse or they were encouraged, which is a sign of how immature the business is.

     

    I'm pretty keen to see anything new just to have something different to talk about. Two things I predict based on previous experience. 1) All predictions will have no bearing on what transpires 2) See 1.

  2. As recently reported in Forbes, SONY has filed for a patent for a system (not yet created) that interrupts a players game-play to show advertisements.

     

    Here's the patent in full.

    Patent: Advertisement Scheme for use with interactive entertainment

     

    I'm frankly baffled why a corporation might actually do this to someone's game. Maybe I'm too sensitive to these things. What does everyone else think?

     

    Would you put ads in your game if you got a little extra in the budget for it?

  3. "Give a man a computer he can surf the web, teach him to program and he'll take my job."

     

    Rick I have much sympathy. Had a little rant about the evils of OOP programming on Google+ a few weeks ago (thus making sure nobody saw it) which has driving up inefficiency of real world resources for the sake of short term design convenience. Computers today are horribly inefficient given how much power they have.

     

    It's not as if you can drop down to one common denominator, op-code as the interfaces on devices are too complex and diverse.

     

    The BSC (British Computer Society - which used to be relevant), put the error rate in source code @ 1 fatal error for every 100 lines, on average. Today IT is given much more authority and trust than it deserves. I personally believe that more control and hand-crafted code is needed as you can't risk not to have that level of scrutiny. The cost of that is increased analysis and testing, more man-years but more robust systems. Also huge budgets which become PR disasters when big projects fail.

     

    If it's just game programming then it doesn't really matter, not like it's going to cure cancer or forget to give someone their prescription.

     

    Best game creator interface I've seen is Little Big Planet 2. Millions of levels of user created content, most of it "meh" but some highly imaginative ones all done by drawing and connecting objects. You might have heard about the difference engine someone made in it. Dot matrix pong was my fav simply because it looked radically different from the host engine.

     

    "Standards are great, there are so many to choose from."

  4. Recently I've been reading Platform Study series of books (MIT press), the one on the Amiga (The Future Was Here) is a bit of a dry read although I didn't know Andy Warhol was at the launch party for it. Interestingly artists looked at computers like this and wondered how you got the picture out. That was the worry. The attitude was art only existed outside in the real-world and printers being **** made the whole effort moot. In Europe the Amiga was focused on games and I didn't realise in the US it was much touted as a multi-media PC, hence the genlock friendly flickering, Newtek, Video Toaster and Babylon 5 from across the pond.

     

    Here in game-land UK I was programming a few Copper demos under the monika "Mike Flex" which got me into more 16bit game programming using AMOS. Just across the way Worms was being written using BLITZ Basic (some expensive language from New Zealand, you might have heard of it) and this went on to be a franchise for Team17.

     

    My friend Gareth went to work for them after he finished work on one of my games (a hex based battletech thing). When he was in Leeds we met up with Martyn Brown for XMAS drinks where he described the editor of a popular Amiga magazine (possibly same one Worms won the competition at) as a "****ed up junkie". Well that's London for you. He's now head-hunting for a new Activision studio in London. (yeah here's the story http://www.eurogamer...home-new-studio ). Martyn Brown gave me some advice, don't tell anyone you wrote your games in a game language or they won't take you seriously. It was seen as something to be ashamed of for some reason. To this day I reject all arguments that language A is better than B. Only thing that matters is what you do with it.

     

    Anyway that's old news. The above list is missing the ATARI VCS, it was an important player as it led to the VIC 20 and beyond.

     

    "Racing the Beam" on the Atari VCS details how all the game logic had to be done when the electron beam was re-positioning as the screen display was drawn by the CPU. The logic for all those games of Asteroids, Space Invaders and Pitfall was literally off-screen, or between scan-lines. Hence the title of the book.

     

    Here's a funny aside about the C64. A close friend of mine drove 25 miles to York to buy a C64 and floppy drive (50 mile round trip), comes home and sets it up. Puts a disk in the drive, typed the load commands as per the manual and...nothing happens. Tries again....nothing. Phone call to shop, they go through the same steps...not working.

     

    He packs up the computer and drives back to the computer store in York. They set up his C64, places a floppy disc into the drive then close the little door on it. "Ah" my pal said, "I think I know what I did wrong."

     

    (yes he didn't close the little flap)

    • Upvote 1
  5. I posted code that didn't work,

    The shaders did look spiffy,

    But Macklebee, you wait and see,

    will fit it in a jiffy,

     

    Quickly edit blog I did,

    In hope that no-one saw,

    To my surprise (and rolling eyes),

    My boss was at the door,

     

    What's this code that you doth post?

    In public, for the shame!

    Quickly thinking, looking round,

    the cat I sought to blame,

     

    Two weeks later, deadline looms,

    my work is almost late,

    I post a rhyme in morning time,

    Just to pro-crast-in-ate.

     

    The end.

    • Upvote 1
  6. So long as I can set a hot key for everything it's not far off from other editors I'm using which also have asset preview panes etc.

     

    post-52-0-95505200-1338059700_thumb.png

     

    With a lot of functions come the hassle of navigation. While the above interface was initially laid out with artists tablets in mind, for us non tablet uses hot keys get used a lot.

  7. I think the key phrase here is "expectation management".

     

    Another key phrase...and it's really...I mean really hard to take this one in, I find it hard to visualise this one..."Man century". That's the level of effort involved in some games now.

     

     

    I'd rather stay a civil engineer for the rest of my life than make games like Minecraft and be a money grabber.

     

    Funny you saying that, one of my fav old games was written by Sandy White (circa 1983), built a virtual city in hex. He was an architect not a programmer by trade. You can even play it from a link here... http://sandywhite.co.uk/fun/ants/

     

     

    Nothing wrong in being successful though. Minecraft deserves it's success, it just happened to give kids what they really wanted instead of what game designers have traditionally been telling everyone what they wanted. I watch my kids use it for all kinds of things. But most of all they use it to tell their OWN stories and share them.

     

    True there's a lot of cynical exploitation, that's any media for you. Find a wagon, chuck a band on it.

     

    Not sure I have much use for another 3D mobile engine when I have two to choose from, although one isn't very good. You still have the same problem of creating fully fleshed out ideas in code regardless.

     

     

    If I can sit down with LE3, drag an animated FBX cartoon boy character onto a plane, attach a third-person controller script, a cube and a pickup trigger and run it on an iPad so I can control him to pick-up the cube...do all that in under 15 mins I might be sold. That's the kind of usability I'm used to today.

  8. Here's a rather extreme example.

     

    A desert scene I generated using the "Desert" procedural modifier on a dense flat grid. The quality of the the dune ridges is filly dependent on the resolution of the base terrain grid.

     

    Once you're happy with construction after adding lighting and shadow maps you can create the mesh layer with little loss of visual quality. You can see the difference in wireframe...

    post-52-0-34176200-1337349611_thumb.jpg

     

    And here's the same scene lit normally...

    post-52-0-68997700-1337349569_thumb.jpg

     

    If I want to keep a really high resolution mesh in the middle because my action scene requires an oasis then I simply retain the high-res terrain tile or generate a higher resolution mesh for that centre tile. You can mix and match resolutions to your hearts desire, one caveat, watch out for gaps between different resolution tiles. Any gaps require you hand edit individual vertices to fix it.

     

    Normally these mesh layers are used on plaftorms that don't support heightmaps (e.g. iPhone Unity pre 3.5) but have application for scene construction elsewhere. Both formats are exported, you can still use the regular heightmap and the lower detail mesh (however many LODs you choose to make).

  9. I've been using something called GROME (GROund Modeling Environment) for a while now, it's a tool for creating realistic landscapes through a mix of procedurally generated techniques and hand editing. Imagine a system blending 3D MAX modifiers for geometry with Photoshop layering for textures and effects. You can export the result as geometry and textures for a variety of engines.

     

    I was talking about the problems of rendering large scale terrains recently and the topic of using "tiles" came up again. This is what I've been using GROME for (on a non Leadwerks project). It works on huge terrain sets, paging in as required and splits them up into separate zones. Each zone can have different resolutions and materials as needed. If you're working on large worlds this is pretty much the business for doing it. Each zone is exported as a discrete mesh. Not only that, you can create multiple LODs for each tile. Simplify individual meshes as required or export the native height-map for that one area.

     

     

    post-52-0-80414700-1337271112_thumb.jpg

     

    While working on art pipelines I wanted to include a Leadwerks one but I'm reasonably pleased with results. Here's a screen-shot showing a single Leadwerks mesh, it has multiple LODs and only a base texture has been applied. Specular and normal is available but not created for this test.

    Ambient occlusion and light mapping was baked in. A material shader for blending detail textures would be a great addition and should be a simple task.

     

    Original "Canyon" scene...

    post-52-0-09719600-1337271210_thumb.jpg

     

    Little fog and lighting adjustment...

    post-52-0-95372600-1337278768_thumb.jpg

     

    Currently the closest output format GROME supports is Collada DAE but the Leadwerks conversion tool dae2fbx doesn't like the input. Need to work on that before I can automate terrain export for Leadwerks. Not a priority since I'm still working on Unity3D scripts for GROME.

     

     

    post-52-0-75810600-1337280527_thumb.jpg

    Large sections of detailed height-maps can be turned into multiple LOD irregular triangle meshes. Easily moved, positioned, swapped in and out for use in a treadmill terrain system.

     

    Once the system has been fully scripted for automated export of an entire terrain there are many other small problems to resolve. The native Leadwerks vegetation would need to be handle paging in data for different zones. Lakes and rivers which work like the Leadwerks water plane except it has a plane for each terrain "tile" and has a mask so it doesn't flood an entire height level. Roads are spline based objects, only the level is baked into an exported terrain mesh. A road object mesh for each zone would need to be constructed, possibly with at least 2 lods.

    • Upvote 1
  10. Offsetting the "world" as you describe Red is a valid technique, it's one way tiled worlds work. What you're wanting to do is add an extra co-ordinate space to everything.

    • World co-ordinates (e.g lat/lon)
    • Tile co-ordinates (e.g. tile[12][13])
    • camera space co-ordinates (e.g a Vec3() position )

    And everything is tied up in a manager to deal with it. Some commercial games exhibit small glitches when crossing these tile co-ordinate boundaries and have to adjust the world. Spatial audio glitches are a clue as the "listener" can lag a little. Sometimes you get rubber-banding in an external view for no apparent reason.

     

    Parent everything within tile space to the tile and you move the tile - thus moving everything with it. You'll be able to do this in my procedural dungeon. In the final part I plan to show how you can create infinite dungeons by exploiting "cells" as a virtual co-ordinate system. Currently each wall is parented to the room mesh, move the room and all the lights, props, wall, go with it. Each room lives in a virtual "cell" space. Replace room with terrain tiles and it's similar, if less sophisticated.

  11. This is the topic for a small book. All these experiments and more were tested in Patrick Cozzi's book "3D Engine Design for Virtual Globes", the books website has small examples for experimenting with depth precision, camera distances, scale. Just to prove the point you can't have your cake and eat it. I highly recommend this book for anyone seriously interested in the problems of terrain and scale.

     

    If you have a cockpit in world space that moves away from the origin (this applies to any 3D engine) you will get vertex jitter. That's it. Obtaining a source code license to try and rebuild the engine for 64bit math is not practical. Both in terms of license cost and ability required - I'm sure Josh uses some arcane matrix shortcuts and it won't be enough simply substituting one type to another.

     

    So that's the negative. Now the positive.

     

    Your solution would be to render the cockpit it in it's own world space. The one in combat helo never leaves the world origin, sames goes for guns and knives. This is layering. It's no different from pasting old school 2D cockpits over the screen, only difference is the 2D image is a 3D model with lighting. Getting everything to match up, exterior models with interior models, lighting etc.is the hard work.

     

    That is the solution for any kind of inventory or vehicle cockpit. It doesn't work so well for exteriors but could be done in a similar fashion.

     

    The panacea is to create a tiled/paged environment so the viewer never strays too far from the origin. Think old scrolling tiled games where you can explore maps bigger than the screen. You have a slightly easier time with this in UnityPro, something I'll be covering in a future book. I hope to have a working Unity example ready in time for publication but it's not a trivial thing. You can't apply transformations to Leadwerks Terrain and you can't have more than one Terrain object so you need to build your own system from scratch. But you have to ask yourself if the game justifies it. Really the easiest thing is just make a smaller game and all the problems go away. Battlefield 3 uses art tricks to make you think you're going faster and further than you are but you're still moving around very small areas, even in jet fighters. That's art trickery and a whole topic of the illusion of speed.

     

    Here's some more practical help and I don't want to spend more time on this as it really is a never-ending topic.

     

    One of the things I did to fudge depth writing on SOME objects to create a second overlay material that was only applied to problem objects (such as rockets inside pods). My MESH.FRAG is far from standard but after the BLOOM conditional I have the following kludge which is applied to an exterior container (eg. rocket pods).

     

    // I need the depth offset proportional to the camera distance from the vertex
    #ifdef LW_OVERLAY2
     float dist = length(modelvertex.xyz - cameraposition ) / 512.0;
     float z = DepthToZPosition(gl_FragCoord.z);
     z = z - dist;
     gl_FragDepth = ZPositionToDepth( z );
    #endif
    



  12. Proland is a tech we were negotiating for a while ago relating to a commercial Air Sea Rescue simulation, pleasingly the lab is making it available under a dual GPL3/commercial license. Here's the text of the announcement
    .

    is pleased to announce that Proland has been released in Open Source:




    Proland is a C++/OpenGL library for the real-time realistic rendering of very large and detailed 3D natural scenes on GPU. It is capable of rendering entire planets from ground to space. Proland is released under a dual GPLv3/commercial license. You can try it by downloading the precompiled Windows demo at
    .



    A complete earth dataset is 20GB but it's interesting technology and flexible too, here's Eric's "RAMA" world...

×
×
  • Create New...