And Then We Had Blessed Cloud
Another fine day in developer land, and the sun has finally retreated behind the cool embrace of Welsh cloud. That means my office is no longer a sauna, and like a Troll, my brain is starting to function again in the cooler air.
I have my little task list for today which comprises mainly of dealing with the last of the map editor fixes. I have knocked my emails on the head this morning so my afternoon is free to code and conceptualise to my hearts content.
Running the current version was quite a good feeling as for the first time in weeks and weeks I can pick a segment, and paint with it without horrors appearing on the screen.
An Art Treat
After days of art-less blogging, I can reveal some new art to you in the form of some animations I left would help the final Reloaded game play experience. Rather than read my whittering, here is Mark to present the extras in this very cool video:
I am particularly excited about the pointing 'while talking' animation as it really opens up a whole new series of features for NPC and Combat interaction. Imagine hiding from a group of enemies, and in the distance you have your zoom lens locked onto the group commander. You see him talk with his men, then suddenly point in your direction, ooh the chills. I must maintain composure each time I see these animations as I know deep down it's the AI and game play that will make or break Reloaded. My current tasks are akin to rebuilding a straight six engine, when the exciting part are the lines of the car and the toys inside!
Remaining Issues
Off the bat I can see the editing does not delete at low LOD, which will need some more data structures and code to support this. The highlighter flickers which indicates which segment is being edited, there is some Z clash on the floor when you paint floor segments down, when you paint quickly, there is a performance hit as the deletion code rapidly removes (or to be added again) segments which is noticeable on my monster rig. That means it will definitely show up on an average machine.
Not sure what order I will tackle these issues, but a nice cup of tea will certainly help the decision making process.
13:45 A Cup Of Tea Later
I have decided to skip optimising the deletion code and leave it slowish for now, so I can focus on adding the required functionality for the map editor. I will doubtless see opportunities for speeding things up as I go along. I have also fixed the highlighting and Z clash issues, so my primary task now is editing in the low LOD areas (which in theory is just an extension of the high LOD deletion system).
14:42 Quick Tip
A nice tip for the new coder. When you are amending a data structure to include new fields or additional dimensions to an array, add the extras to the data structure and all the code that used the former structure, but don't add any new functionality associated with the new additions. Get your app working as before so you know existing functionality is in tact before expanding your code and using the new fields and data for the intended purpose. This way you are only fighting one fire at a time :)
14:56 Low LOD Deletion Done
Using my super tip, I was able to step through the logical steps to increase the capabilities of the delete code to include the larger low LOD area, and now I can paint and delete at any level of editing, which is great!
In testing this though, I found a new issue which was that when you overlay two segments on top of each other (which is fine), when it comes time to delete the crossed segments, they stay there. It gets worse, as in another test when I drew a segment over another one, two more segments that neighbour them also refused to delete. Just like bubbles, you push one down and another pops right back up :)
15:18 LOD Transition fixed
Before I could solve the above, I noticed the LOD transition was off on segments in the positive directions, now fixed and it's great to see an almost perfect transition in LOD right up until the camera clipping plane eats them. Something we never had in FPSC classic so a great addition!
15:29 Multiple Deletions Are Go
I disabled the code which only deletes segments of the same type and now we have no left-over segments, hurray! If I don't probe too deeply, I can be quite happy with how the map editor now behaves with the new instance stamp implementation. It does not do segment overlays, entities, lights or anything else you might associate with the editor, but segment editing, memory handling, rendering and LOD are all working nicely.
15:48 Eye Candy
Earlier today I was interrupted by Rick with the request to have some 'decent' stuff to show in a few weeks time when I disappear for my two week vacation. I only have one 'test' segment, which really does not help me construct a detailed game shot :) To this end I fired off an email to Mark to start the serious work around segments, scenes, shaders and all things beginning with S. While I wait for that reply, I have decided to derail my current work to get the map editor 100% back to factory functionality, and instead switch over to 'fancy visuals' mode.
Before I mentally switched tracks (about ten minutes), I created a small scene (oh, you can't save and load levels either as the level constructor code still uses the old system) which was a very very long tunnel from one end of the level to the other. As I ran down it, I considered how great it would be to use a shader to demonstrate parallax rendering here, and also to experiment with other visual techniques for shadows, lighting and anything else we need for the final shader.
Signing Off
I just noticed how long this blog was getting, and I don't want to be accused of spending all my time blogging about Reloaded instead of coding it, so I will end here. The rest of the day and evening will be working on the new shader prototype, which will be designed to drop into the map editor and allow that wonderful shaded tunnel scene I described above.
Hopefully in the next two weeks you will see some nice eye candy and visuals to excite you about Reloaded. It's not the best time to pull away from the map editor functionality work (as it's fresh in my mind), but the shader work is also time critical as Mark needs these early results. It will also be fun too!
Thứ Ba, 11 tháng 6, 2013
Thứ Hai, 10 tháng 6, 2013
Monday Progro
Good Editor Work
A good day of coding done and more of the map editor is now working nicely. Multiple textured segments being drawn, modified and removed. Scrolled out of the visual area then scrolled back, and also LOD working when you pull out to view the whole scene or from first person view, in the distance.
In testing my new code creations, new issues did surface such as not being able to 'delete' in the low LOD regions which was deliberate. I assumed that editing would be done up close in high LOD areas, but I quickly saw myself zooming right out and then painting a monster huge room, which added fine but I could not delete it with the same art tool. Something for Tuesday's list.
The Long Road
Signing Off
I clocked another two hours this evening to bash down the emails, write this blog, and sort out my wish list for Tuesday. I did a little work on the shader for the current SAND segment which is the ONLY Reloaded asset for map editing right now. This is in preparation for dropping in a better shader from the new prototype which will eventually furnish the goodies. Not only will I be exploring deferred rendering in this prototype, but working with Mark to conjure a shader that gives us a great universal set of visual attributes that the whole scene, both static and dynamic can utilise. Unlike FPSC Classic, we want Reloaded to feel like every pixel belongs in the same scene.
A good day of coding done and more of the map editor is now working nicely. Multiple textured segments being drawn, modified and removed. Scrolled out of the visual area then scrolled back, and also LOD working when you pull out to view the whole scene or from first person view, in the distance.
In testing my new code creations, new issues did surface such as not being able to 'delete' in the low LOD regions which was deliberate. I assumed that editing would be done up close in high LOD areas, but I quickly saw myself zooming right out and then painting a monster huge room, which added fine but I could not delete it with the same art tool. Something for Tuesday's list.
The Long Road
I would probably have done much more code today where it not for a curious detail of everyday development. The actual code changes to fix the above could be done in a few minutes given a super-human brain, but regular humans take a little longer. The issue was not fixing the code, but finding which code was responsible for erroneous data. When that erroneous data is buried deep deep inside a data structure system that needs five minutes of software usage before the issue emerges you find it almost impossible to even remember what you where originally looking for.
To help me on this quest, I used my handy notebook to sketch out a map of all the data as it was being created, so that I could stay oriented as I mined through nests upon nests of indirect data. Fortunately, persistence and a pen paid off and I was able to enjoy a hassle from map editing experience as the clock tolled 6PM.
Hopefully segment art will appear in the next two weeks which means you will start to see some nice videos of all this boring Technic stuff ;) Rick is positively leaping up and down for the visual side of things to mature so for those waiting for the eye candy, you have a champion on the inside working for you.
I clocked another two hours this evening to bash down the emails, write this blog, and sort out my wish list for Tuesday. I did a little work on the shader for the current SAND segment which is the ONLY Reloaded asset for map editing right now. This is in preparation for dropping in a better shader from the new prototype which will eventually furnish the goodies. Not only will I be exploring deferred rendering in this prototype, but working with Mark to conjure a shader that gives us a great universal set of visual attributes that the whole scene, both static and dynamic can utilise. Unlike FPSC Classic, we want Reloaded to feel like every pixel belongs in the same scene.
Chủ Nhật, 9 tháng 6, 2013
Weekend Deleteathon
A Day Of Deleting
As you may know the task this time is to finish the map editor editing system and then move swiftly onto some deferred rendering prototypes. Alas.
I made good progress with improving the map deletion code, which was 94% searching and 6% fixing due to insane reproducibles. One example would be use a large radius spray can to spray over an area of 100x100 grid tiles, then return to the initial corner and delete a few segments at random. The bug being that some will not delete. Now try reproducing that exactly so you can trace the hundred fold nests to see what the contents of arrays of floats buried behind double jump reference pointers. It's no picnic!
Some Good News
Even though deferred rendering is now a distant ambition for the weekend, it looks like I am very close to cracking the editor delete stuff and only have some low LOD issues to tackle (they don't go away when the high LOD is in play) and as the delete code only handles high LOD geometry, it makes it look like the tile was not deleted when in fact it's the low LOD I am now looking at.
To be fair though, adding and subtracting from buffers and a cascade of variations was always going to be a tricky one to test and refine, and when you mix in multiple overlapping buffers you know you're in for a world of pain. With a little luck, I can put these glitches on the fixed list and have a working editor come Monday.
Signing Off
Sorry no pictures today but everyone went home and left me with my programmer art hands. I have thrown out a few emails in order to get some content this week so watch this space for the graphical stuff :) For more technical headaches and insights, join me on Monday for more lovely ranting! Also, for the many new users who have subscribed to my YouTube channel, thanks muchly. I would ask though that you direct all your comment questions to the blog so I can answer everything in one place and have a single location for all answers Reloaded flavoured. Thanks again!
As you may know the task this time is to finish the map editor editing system and then move swiftly onto some deferred rendering prototypes. Alas.
I made good progress with improving the map deletion code, which was 94% searching and 6% fixing due to insane reproducibles. One example would be use a large radius spray can to spray over an area of 100x100 grid tiles, then return to the initial corner and delete a few segments at random. The bug being that some will not delete. Now try reproducing that exactly so you can trace the hundred fold nests to see what the contents of arrays of floats buried behind double jump reference pointers. It's no picnic!
Some Good News
Even though deferred rendering is now a distant ambition for the weekend, it looks like I am very close to cracking the editor delete stuff and only have some low LOD issues to tackle (they don't go away when the high LOD is in play) and as the delete code only handles high LOD geometry, it makes it look like the tile was not deleted when in fact it's the low LOD I am now looking at.
To be fair though, adding and subtracting from buffers and a cascade of variations was always going to be a tricky one to test and refine, and when you mix in multiple overlapping buffers you know you're in for a world of pain. With a little luck, I can put these glitches on the fixed list and have a working editor come Monday.
Signing Off
Sorry no pictures today but everyone went home and left me with my programmer art hands. I have thrown out a few emails in order to get some content this week so watch this space for the graphical stuff :) For more technical headaches and insights, join me on Monday for more lovely ranting! Also, for the many new users who have subscribed to my YouTube channel, thanks muchly. I would ask though that you direct all your comment questions to the blog so I can answer everything in one place and have a single location for all answers Reloaded flavoured. Thanks again!
Thứ Bảy, 8 tháng 6, 2013
Remembering WEIZAC: the beginning of computing in Israel
Israel is now one of the world’s tech powerhouses, second only to Silicon Valley as a hub for startups, but it wasn’t always this way. Today, in honour of the 84th birthday of Professor Aviezri Fraenkel, we’re delighted to share a short film sharing his story of working on the WEIZAC, Israel’s first computer.
Short film produced with support from Google as part of our ongoing computing heritage series
The impetus to build a computer in Israel came from Professor Chaim Pekeris, an MIT-trained geophysicist and mathematician, who made it a condition of accepting a job at the then-fledgling Weizmann Institute. An illustrious committee was set up to consider Pekeris’s request and initially opinion was divided. In particular, Albert Einstein was skeptical a computer in Israel would receive sufficient use and queried whether the skilled resources to build it were available. It took much convincing by another committee member, mathematician and computing luminary John Von Neumann, before the project got the go-ahead.
Construction of the WEIZAC (“Weizmann Automatic Calculator”) got underway in late 1953 under the leadership of Professor Pekeris and Jerry Estrin. A protege of Von Neumann, Estrin arrived in Israel armed with design drawings based on the computer at the Institute of Advanced Study in Princeton. After advertising for recruits, a small team of engineers and technicians was assembled, among them Aviezri Fraenkel.
It took the team a lot of ingenuity to source the necessary materials. Some were imported, but others were clever adaptations, such as the thin copper strips that came from a small local bicycle-part shop! Despite such hurdles, progress was steady, and the major components were in place by the time Estrin returned to the U.S. 15 months later.
The WEIZAC performed its first calculation in October 1955 and was soon much in demand by Israeli scientists. It remained operational until the end of 1963—50 years ago this year. Nowadays it resides in the Weizmann Institute’s Ziskind Building as a fitting memorial to where computing in Israel began.
I have fond memories of passing by the WEIZAC every day when I studied at the Weizmann Institute, where I also had the privilege to attend a class by Professor Fraenkel. With the release of this short film, I’m delighted to be learning more from him about such an important chapter in Israel’s tech history.
Posted by Yossi Matias, Senior Engineering Director, Head of Israel R&D Centre
Short film produced with support from Google as part of our ongoing computing heritage series
The impetus to build a computer in Israel came from Professor Chaim Pekeris, an MIT-trained geophysicist and mathematician, who made it a condition of accepting a job at the then-fledgling Weizmann Institute. An illustrious committee was set up to consider Pekeris’s request and initially opinion was divided. In particular, Albert Einstein was skeptical a computer in Israel would receive sufficient use and queried whether the skilled resources to build it were available. It took much convincing by another committee member, mathematician and computing luminary John Von Neumann, before the project got the go-ahead.
Construction of the WEIZAC (“Weizmann Automatic Calculator”) got underway in late 1953 under the leadership of Professor Pekeris and Jerry Estrin. A protege of Von Neumann, Estrin arrived in Israel armed with design drawings based on the computer at the Institute of Advanced Study in Princeton. After advertising for recruits, a small team of engineers and technicians was assembled, among them Aviezri Fraenkel.
It took the team a lot of ingenuity to source the necessary materials. Some were imported, but others were clever adaptations, such as the thin copper strips that came from a small local bicycle-part shop! Despite such hurdles, progress was steady, and the major components were in place by the time Estrin returned to the U.S. 15 months later.
The WEIZAC performed its first calculation in October 1955 and was soon much in demand by Israeli scientists. It remained operational until the end of 1963—50 years ago this year. Nowadays it resides in the Weizmann Institute’s Ziskind Building as a fitting memorial to where computing in Israel began.
I have fond memories of passing by the WEIZAC every day when I studied at the Weizmann Institute, where I also had the privilege to attend a class by Professor Fraenkel. With the release of this short film, I’m delighted to be learning more from him about such an important chapter in Israel’s tech history.
Posted by Yossi Matias, Senior Engineering Director, Head of Israel R&D Centre
Thứ Sáu, 7 tháng 6, 2013
Friday mobilious
Lee is out at the moment
As promised here is my Friday blog. I am trying a blog from my phone to see what capabilities I have. It is not ideal as I cannot. control font and bold. Eek!
Signing off
Not my shortest bblog but I wanted to post that I will be coding Saturday so stay tuned! The plan is to finish and fix the map editor delete functionality and play with some deferred protos.
As promised here is my Friday blog. I am trying a blog from my phone to see what capabilities I have. It is not ideal as I cannot. control font and bold. Eek!
Signing off
Not my shortest bblog but I wanted to post that I will be coding Saturday so stay tuned! The plan is to finish and fix the map editor delete functionality and play with some deferred protos.
What the ...?
Dear Google users—
You may be aware of press reports alleging that Internet companies have joined a secret U.S. government program called PRISM to give the National Security Agency direct access to our servers. As Google’s CEO and Chief Legal Officer, we wanted you to have the facts.
First, we have not joined any program that would give the U.S. government—or any other government—direct access to our servers. Indeed, the U.S. government does not have direct access or a “back door” to the information stored in our data centers. We had not heard of a program called PRISM until yesterday.
Second, we provide user data to governments only in accordance with the law. Our legal team reviews each and every request, and frequently pushes back when requests are overly broad or don’t follow the correct process. Press reports that suggest that Google is providing open-ended access to our users’ data are false, period. Until this week’s reports, we had never heard of the broad type of order that Verizon received—an order that appears to have required them to hand over millions of users’ call records. We were very surprised to learn that such broad orders exist. Any suggestion that Google is disclosing information about our users’ Internet activity on such a scale is completely false.
Finally, this episode confirms what we have long believed—there needs to be a more transparent approach. Google has worked hard, within the confines of the current laws, to be open about the data requests we receive. We post this information on our Transparency Report whenever possible. We were the first company to do this. And, of course, we understand that the U.S. and other governments need to take action to protect their citizens’ safety—including sometimes by using surveillance. But the level of secrecy around the current legal procedures undermines the freedoms we all cherish.
Posted by Larry Page, CEO and David Drummond, Chief Legal Officer
You may be aware of press reports alleging that Internet companies have joined a secret U.S. government program called PRISM to give the National Security Agency direct access to our servers. As Google’s CEO and Chief Legal Officer, we wanted you to have the facts.
First, we have not joined any program that would give the U.S. government—or any other government—direct access to our servers. Indeed, the U.S. government does not have direct access or a “back door” to the information stored in our data centers. We had not heard of a program called PRISM until yesterday.
Second, we provide user data to governments only in accordance with the law. Our legal team reviews each and every request, and frequently pushes back when requests are overly broad or don’t follow the correct process. Press reports that suggest that Google is providing open-ended access to our users’ data are false, period. Until this week’s reports, we had never heard of the broad type of order that Verizon received—an order that appears to have required them to hand over millions of users’ call records. We were very surprised to learn that such broad orders exist. Any suggestion that Google is disclosing information about our users’ Internet activity on such a scale is completely false.
Finally, this episode confirms what we have long believed—there needs to be a more transparent approach. Google has worked hard, within the confines of the current laws, to be open about the data requests we receive. We post this information on our Transparency Report whenever possible. We were the first company to do this. And, of course, we understand that the U.S. and other governments need to take action to protect their citizens’ safety—including sometimes by using surveillance. But the level of secrecy around the current legal procedures undermines the freedoms we all cherish.
Posted by Larry Page, CEO and David Drummond, Chief Legal Officer
Thứ Năm, 6 tháng 6, 2013
Thursday Edits
Back In The Engine
Well my sunburn subsided and I was able to get some coding done. The task of the day was to get the system to handle multiple textures, not just the single texture mesh I was throwing at it so far.
A Maze Of Texture Complexity
Sounds easy enough you would think to add some texture goodness in there, but it turned out the whole system hinged on the fact a single buffer would be created to handle an area of the map. As it happens, for multiple textures to exist, multiple buffers where needed to be created that overlaps other buffers many times. Not so bad in terms of memory usage, but performance took a hit as more buffers where created on demand as new textures appeared, and also the draw call count increased as there are more buffers in the same scene space, each holding their specific texture.
In my prototype, this resulted in a very notification drop in frame rate when segments of 17 frames where stacked left, right and up in front of the viewer (worst case scenario). During the map editor tests, the performance hit was not noticeable as segments are drawn in much much fewer quantity, and the final result will only really be known when we start throwing real scenes at it. It is a necessary addition, and I hope it does not force me into too much distracting optimization work, but there are a few easy speed ups in there I am sure.
The good news is that it's in now, and I can paint segments of different textures, and segments that contain different textures inside them too. I did notice too that only the first segment permutation was drawn, which meant I could not add subsequent walls, floor, e.t.c. That lead me to my next piece of code.
Inter-Tile Editing
A feature of the new instance stamp system is that to change the scene, you must first remove the reference from the map and buffers, and then add a new instance of the object with any changes required such as limb visibility and rotation. A very instant task for sure, but when the tile is already filled it skipped the delete part.
After adding this new code, I could now add walls and floors like a trooper. The downside is that for some reason the delete code can occasionally target other polygons and remove them. I noticed this before, but now this new code is in it is much more reproducible.
My priority task Friday evening will be to find and fix this remaining issue and we will have a 'sort of' working map editor that allows different segments to be added, edited in place and removed from the 500x20x500 scene :)
Art News
No new art to show you today, but I can report that Mark's brain is now irrevocably set to segment art thinking mode, so expect juicy segment and scene art in the weeks to come. I can't wait!!
Signing Off
I have a busy road day Friday as my mail order department shifts 108 miles from Wales to Wigan for 2 weeks as my chief mail order dudette takes a well earned break, and my equally hard working Wigan dudette takes over. This will mean my morning and afternoon will be out of the office, but I plan to throw down a few hours that evening and spend a good part of Saturday chasing this code down too. All in all, quite pleased with how the map editor is slowly being put back together.
Well my sunburn subsided and I was able to get some coding done. The task of the day was to get the system to handle multiple textures, not just the single texture mesh I was throwing at it so far.
A Maze Of Texture Complexity
Sounds easy enough you would think to add some texture goodness in there, but it turned out the whole system hinged on the fact a single buffer would be created to handle an area of the map. As it happens, for multiple textures to exist, multiple buffers where needed to be created that overlaps other buffers many times. Not so bad in terms of memory usage, but performance took a hit as more buffers where created on demand as new textures appeared, and also the draw call count increased as there are more buffers in the same scene space, each holding their specific texture.
In my prototype, this resulted in a very notification drop in frame rate when segments of 17 frames where stacked left, right and up in front of the viewer (worst case scenario). During the map editor tests, the performance hit was not noticeable as segments are drawn in much much fewer quantity, and the final result will only really be known when we start throwing real scenes at it. It is a necessary addition, and I hope it does not force me into too much distracting optimization work, but there are a few easy speed ups in there I am sure.
The good news is that it's in now, and I can paint segments of different textures, and segments that contain different textures inside them too. I did notice too that only the first segment permutation was drawn, which meant I could not add subsequent walls, floor, e.t.c. That lead me to my next piece of code.
Inter-Tile Editing
A feature of the new instance stamp system is that to change the scene, you must first remove the reference from the map and buffers, and then add a new instance of the object with any changes required such as limb visibility and rotation. A very instant task for sure, but when the tile is already filled it skipped the delete part.
After adding this new code, I could now add walls and floors like a trooper. The downside is that for some reason the delete code can occasionally target other polygons and remove them. I noticed this before, but now this new code is in it is much more reproducible.
My priority task Friday evening will be to find and fix this remaining issue and we will have a 'sort of' working map editor that allows different segments to be added, edited in place and removed from the 500x20x500 scene :)
Art News
No new art to show you today, but I can report that Mark's brain is now irrevocably set to segment art thinking mode, so expect juicy segment and scene art in the weeks to come. I can't wait!!
Signing Off
I have a busy road day Friday as my mail order department shifts 108 miles from Wales to Wigan for 2 weeks as my chief mail order dudette takes a well earned break, and my equally hard working Wigan dudette takes over. This will mean my morning and afternoon will be out of the office, but I plan to throw down a few hours that evening and spend a good part of Saturday chasing this code down too. All in all, quite pleased with how the map editor is slowly being put back together.
Đăng ký:
Bài đăng (Atom)