The Carbon Development Platform will include elements of blockchain technology, the same used in new survival game Project Awakening, but Pétursson recognises the ongoing scepticism around this tech and emphasises that it is entirely optional.

"If there's anything I've learned from all this is that you shouldn't curb the emergent potential by having too specific an idea of what is going to happen," he answers. "I know from [experience] when you give tools to people in a community, they will make awesome things. This is the story of human life, and they will outdo your creativity way more than you think. Every time you try to put a lid on it, you curb the potential. Make it open, and the sky is the limit.

If you want me to write your program for you I can probably do that, although it would be in assembly language. Please remit $100 in small used bills (or a Gator) to get me started.

"Real friendships are about people investing in each other's destiny. In a way, if you have a problem in life, you will call your friends. Eve Online routinely creates this scenario [because] people fall in harm's way all the time. You know who your friends are because you've had to call them to rescue you and they did come. So, I think our role is that we've made a game of consequence."

This agrees with my criteria which maintains that the comments should almost always be language independent. You should be able to use the same comments in an assembly language program as in a C program (and in a flowchart as well).

I thought I provided an algorithm in the second paragraph of Reply #3. The reason that I used the words "I assume" at the beginning of that paragraph is because I have never actually read from the LCD RAM. I have however used this technique to read the busy flag which uses essentially the same techniques.

If you pulse the Enable to get the next nibble and the display gets corrupted this means that you are not reading data from the LCD as you intended but you are writing data to the controller instead (which is what I said in reply #5).

I would start by liberally sprinkling your program with nice long time delays and see what happens. If that doesn't work I have some more troubleshooting ideas in mind.

Take a look at page 42 of the datasheet http://www.sparkfun.com/datasheets/LCD/HD44780.pdf for more detail on how 4 bit operations work.

You and I, my good sir or madam, think very much alike. This statement made chuckle, as I've always say similar stuff ;D.

Having this data at hand now, and also, whilst apologizing for any misunderstandings/conflicts/headaches/irateness that may posts have caused, I shall post the question again, what to do?

"If you think of what blockchain really is, it's just a weird database and Eve Online is actually the first database game ever made. It's based on SQL server from Microsoft. I had to debate people 20 years ago on whether you should use a database to build a virtual world. People were saying databases are slow, they are not fit for purpose for games and so on. Here we are 20 years later, and databases were fine. Now we have a weird database, and you can use it for whatever. Unfortunately people do tend to use it for not very long-term oriented projects. We are here in the business of doing long-term oriented projects.

As you probably know, when you write information to the LCD module in four-bit mode it temporarily stores the first group of four bits that it receives (with the first enable pulse). After it receives the second group of four bits (with the second enable pulse) it reassembles them into an eight bit byte and deals with the reassembled byte.

The LED controller has 80 bytes of DDRAM with each byte corresponding to a specific location on an 80 character (40 x 2 or 20 x4) display. The Controller continuously scans this memory and for each location it reads the information in DDRAM, uses that information (as an address) to access CGROM or CGRAM and uses the CGROM/RAM data it finds at that address to put the corresponding character on the display. If you change the data at one of the DDRAM locations then the character displayed at the coresponding display location will change. Looking at it the other way - the only way to change what is on the display is to change the information in the DDRAM and the only way to change what is in DDRAM is to write information to the LCD controller.

I'm not trying to get into a pissing match here but my background is in engineering, not horseshoes or hand grenades. I interpret ther term 'quote' as an exact copy of what was originally said. Reply #2 mentions the next "bit". Reply #4 mentions the next "nibble". Reply #6 mentions the next "bits". I used to tell my students that the implication of not being precise in the explanation of ones work is that perhaps the work itself isn't as precise as it should be.

Edit: I just committed the entire code I have for this library to my subversion repo in google code. The code is available here. It is all GPLv3. Since the lcd_getRaw() function is suspected to be broken, the lcd_getState() function is not made to use the lcd_getRaw() function.

"Once we open source it, it belongs to the world," he says. "So, in a way, we're getting out of the proprietary engine business by open sourcing the whole thing. But it's done with the principle [that] it's just more likely to prosper under that setting rather than hidden away in a basement somewhere."

I'm sorry, but that is not what you said. Since you have provided almost no information about your program I did the best with what you did provide.

"Companies generally don't live very long," he explains. "CCP is already quite an old company by gaming standards. We're not Nintendo, we haven't been here for 200 years, but we're 27 – that’s already quite long because game companies are just not very likely to live for a long time."

"Linux is often used to run blockchain nodes, but you don't have to use it [for that], you can use it for whatever," he says, returning to his earlier example. "Our engine is the same, it's made of several components. You can just have a mix and match as you want.

This, however, fails, and the output is corrupted for some reason. Perhaps I made something overflow somewhere, I don't know. The code looks fine to me, in case anybody has any suggestions, please, let me know.

By the way, keep in mind that these timing problems just get worse as processor speeds increase and LCD controller speeds stay essentially the same. To make your code more repairable in the future I recommend that for each time delay specified in the LCD datasheet you include at least a comment to that effect at the point in your program where that time delay would occur.

GamesIndustry.biz is owned by Gamer Network Limited, an IGN Entertainment company and subsidiary of Ziff Davis. © 2024 Gamer Network Limited, 18 Mansell Street Level 3, London, E1 8AA, United Kingdom. Company number 03882481. All rights reserved. No part of this website or its content may be reproduced without the copyright owner's permission.

This process gets repeated until the upper limit is reached. If the display was operating on 8 bit mode, we end up with the full byte by the end of the loop, and it is returned. If the display is in 4 bit mode, we only have one nibble [D3][D2][D1][D0], the if clause executes.

"When you're making a shooter, you have to have an extremely good reason not to use Unreal, and our Carbon platform is not to make shooters. It's really made for making spaceships at serious scale."

As I said, I already tried the approach of sending a pulse to the strobe [enable pin], to retrieve the second nibble. That did not work. The screen output is corrupted if that is done.

I tried sending a pulse to the strobe (enable) to get the next bits, but that caused undesired side effects, like text randomly disappearing from the screen, which leads me to believe that approach is wrong.

He suggests that theme parks are more directed experiences, whereas playgrounds are a more free-for-all affair and therefore potentially more open to negative experiences, such as bullying, and the need for friends as backup.

"There is a fundamental core to Eve Online – it's the first line written in the game design document – which is [that] death is a serious matter," he explains. "And this relates to the death penalty in the game, and the fact that players can really be quite violent to each other.

Evaluating bitwise OR: As per Boolean Algebra: 0 OR 0 = 0 0 OR 1 = 1 1 OR 0 = 1 1 OR 1 = 1 C/C++ Operator for this operation is |

He adds that many of the other engines aren't built specifically around the kind of scale Eve operates on, pointing to the size of its in-game universe and citing the 10,000-player battles the MMO has managed to accommodate. He also observes that sharing Carbon means its internally-developed tech no longer classes as proprietary.

This should be the same algorithm that is used in the current LiquidCrystal library that comes with the Arduino IDE, only the way it is implemented there is too bloated for my taste in programming.

being a two or three digit number. If distance was less than 25 cm, it would show "PROXIMITY WARNING" on the second line. Instead, it showed "

We're catching up with Pétursson ahead of his Develop:Brighton talk next week, where he explored how Eve Online has created "resilient communities" around itself. It's a subject he has spoken passionately about before – although he admits that how the players have interacted with each other is "a happy accident" from one of the fundamental parts of Eve Online's design.

In several posts you have stated that you have pulsed the Enable to get the next nibble but you have not mentioned anything about all the other steps that must be taken to read data from the LCD controller. I assume that you know what these steps are since they are also used in the 8-bit implementation which you imply you have done in your original post.

"We want Eve Online to go on forever. Open sourcing the platform that powers it in my view is greatly increasing the odds of that happening."

I assume that when you read information from the LCD module in four-bit mode your program would have to do essentially the same thing. You would send an enable pulse, read the incoming data (the upper four bits of the incoming byte) and stash it away. You would then generate another enable pulse, and read the incoming data (the lower four bits of the incoming byte). You then have to do some swapping, masking, ORing etc. to reassemble the byte.

Observations This is obviously a backend to be used by other functions which will filter the data for the end user. At some point in time in the execution, the LCD's output gets corrupted, some things disappear.

Retrieving data from the LCD module should not corrupt the display. You have to write data to the LCD module in order to do that. So your program code must be changing the R/W line between the Enable pulses or something along those lines....

Lcd1602datasheet

It's an interesting move at a time when some studios are shifting towards more widely used engines rather than using their own tools. Last year, CDP confirmed it was dropping its proprietary tech in favour of Unreal Engine 5 when working on the next Witcher game, while Crystal Dynamics has also chosen Epic's tech for the next Tomb Raider.

We loop to get data out of the LCD. The first loop is generic and gets executed no matter whether the LCD is in 8 bit mode or 4 bit mode. The process is simple:

I need to read from an HD44780-based LCD screen in 4 bit mode. What else do you need to know in order to provide an algorithm?

"I believe you can use this database to build something unique, but I'm not here to bless the technology, per se. Tech is just tech. You can use whatever tech to good and bad means."

1602 LCD

Assuming the LCD is in 8 bit mode, the following is executed: i=0) [B7][B6][B5][B4][B3][B2][B1][B0] >> 0 = [B7][B6][B5][B4][B3][B2][B1][B0] [B7][B6][B5][B4][B3][B2][B1][B0] & 0x01 = [B0] [B0] is then written to datapin[0] i=1) [B7][B6][B5][B4][B3][B2][B1][B0] >> 1 = [B7][B6][B5][B4][B3][B2][B1] [B7][B6][B5][B4][B3][B2][B1] & 0x01 = [B1] [B1] is then written to datapin[1] and so on, until all data is written.

If the LCD is in 8 bit mode, the second loop is the only one that executes. The operation in question is extracting the least significant bit not sent. This is done by bitshifting the data to the right n places and bitwise anding with dec1 (b00000001).

Thanks floresta. I think I can live without the extra 48 bytes (presumably) my 16*2 is keeping from me. I have pin 5 tied to ground anyway so read is a non starter.....

The library in question is supposed to be an extension (separate library) to my LCD library found in Google Code. With that being said, I have no immediate use for it, it is something that I'd like to have for the future (food for the winter if you will). The code I use I no longer have, deleted it before I committed it to my subversion repository (big mistake, I know), so I have no reference to show. The code was, however, bug free.

HD44780

To filter out the busy flag, all that needs to be done is bitshift the return value 7 places to the right, which leaves [B7] by itself. To filter out the Address Counter a bitwise AND can be performed with 127dec (01111111), leaving [B6]-[B0].

You have finally provided enough information for me to make some more educated guesses. From the information in your last two posts it appears to me that you do indeed know the signal flow involved in reading and writing in both 4 and 8 bit modes. Since I am not much more than a rookie C programmer I will assume that your C code is correct as well. I still stand by my analysis that in order for the display to become corrupted the DDRAM has to be getting messed up somehow.

"Also, when the whole code is open source, it's way easier to work with the universities. We could do game jams over summer, having people contribute, it's open with no legal complications. So there's a myriad of opportunities that open up once you've set it free."

As announced earlier this year, the company is planning to make its proprietary Carbon Development Platform – which encompasses the studio's Carbon Engine and other technology – an open source property, giving other developers their chance to get to grips with the same tools behind CCP's flagship title.

"That is maybe the role of the developer, it's to choose. Are you making a playground? Are you making a theme park? Every MMO is a mixture of both, but what are the ratios? How are you going to tune the experience? But then the rest is made by the people playing the game."

Here is lcd_sendRaw(). The algorithm is pretty much the same concept, except that instead of reading from the LCD, we write to the LCD.

This function gets called whenever we need to get the status flag or any address. The status flag is simply obtaining by bitshifting 7 places to the left

Pétursson notes that CCP is doing a mix of both. While Eve will continue to be developed in Carbon, the studio has opted for Unreal when making Eve Vanguard, a new first-person shooter set in the same universe.

Bitshifts: Bitshifting is an operation done to, of course, bits. As the name implies, all that is done is shift to the right or left. A left bitshift by n is equivalent to multiplying by 2^n. A right bitshift by n is equivalent to dividing by 2^n. Examples: (bitshift two one to the left) dec2 << dec1 = bin10 << dec1 = bin100 = 4 (bitshift two one to the right) dec2 >> dec1 = bin10 >> dec1 = bin1 = 1 (the zero gets dropped)

A question if I may, and please take no offence on it, was my code that obfuscated that it needed documentation? It is not my intention to write unreadable code. I consider obfuscated code to be bad code.

There are also some setup times, some hold times and also the Enable cycle time that should be considered. I don't know the ramifications of not meeting some of these requirements. I would suspect that the device would just not work, but in your case you could be right on the borderline with even more spetacular results.

The data to be written is stored in an unsigned 8 bit integer (char type). For ease of reading, we use an unsigned 8 bit integer as defined in . The data has the form [B7][B6][B5][B4][B3][B2][B1][B0].

If you want me to write your program for you I can probably do that, although it would be in assembly language. Please remit $100 in small used bills (or a Gator) to get me started.

"We want Eve Online to go on forever. Open sourcing the platform that powers it in my view is greatly increasing the odds of that happening"

Using returned data The data returned will have the form [B7][B6][B5][B4][B3][B2][B1][B0]. What the data represents depends on value fed to register select (rs_pin). If rs_pin is given a LOW, then [B7] is the busy flag status and [B6]-[B0] will contain the Address Counter. If rs_pin is given a HIGH, then the return value will be data from DDRAM or CGRAM.

As I said, I already tried the approach of sending a pulse to the strobe [enable pin], to retrieve the second nibble. That did not work. The screen output is corrupted if that is done.

Now, the operation in question is trivial to implement when using 8bit mode, as all data channels are available. The question is, when working in 4bit mode, how is the data read then? I can't find any available documentation on this subject. Any help would be appreciated. Thanks

But you haven't provided any code to show how you are attempting to retrieve and deal with this data so all I can do is guess at what is wrong, which is what I did in the second part of reply #5. The scenario that I guessed at is consistant with the description of the behavior that you gave.

cm", with

It's no worse than most other C code that I try to read. Some programmers seem to believe that C is 'self commenting' which is a real joke. Let them try to figure out a program that someone else wrote or one that themselves they wrote ten or fifteen years ago and then see what they say about comments.

"You can also see [this with] Unreal Engine, which is a pretty big deal in the industry. The source for Unreal is readily available to everyone – it’s not an open source project, but the source code is there. It’s immensely helpful."

In case of 4 bit mode 5) Bitshift retVal 4 places to the left. This puts the nibble as the upper end of the byte. [D3][D2][D1][D0] << 4 = [D3][D2][D1][D0]0000 6) Trigger the strobe (This is what this entire argument has been about, and what I am not sure that should be the proper procedure). 7) Repeat process above to get the second nibble. By the end of the loop, the lower end of the byte will be completed and retVal can be returned.

It's kind of obscure, but if you are using a display with less than 80 characters (such as a 16 x 2) it is possible to use some of the DDRAM in the LCD controller for general data storage. I don't know why anyone would want to do this, but it is a possibility.

At April's London Developers Conference, Pétursson gave a similar talk on community, regaling attendees with tales of players who have formed real-world friendships and even marriages after spending time in Eve. But how much credit can a developer claim for how its community connects?

Read the first pin (i = 0), this is the least significant digit. In 4 bit mode, this would be data pin 4 on the LCD board, in 8 bit mode, this would be data pin 0. The output is either a HIGH (1) or LOW (0). Let the reading be the bit [D0]. It gets bitshifted by zero places to the left. The operation performed will be: 0 | [D0] = [D0] which is stored back in the return value.

Read the second pin (i = 1). Let the output of this be the bit [D1]. It gets bitshifted one to the left and OR'ed to our return value: [D1] << 1 = [D1]0 [D0] | [D1]0 = [D1][D0]

The timing part I know is something I am missing. If you look over lcd_init() over at my subversion repo at Google Code, you will find that initialization is not done properly either. I planned to add this at some point, it looks however, that it may be the root of the issue. The lcd_sendCommand() and lcd_sendChar() functions however rely on reading the busy flag and waiting for the LCD to become available again before exiting.

If the LCD is in 4 bit mode, the byte must be sent in nibbles. The second loop is generic and can send the low end of the nibble (loops from i = 0 to 3, yielding B0 to B3). The first loop is executed before in this case. i=0) [B7][B6][B5][B4][B3][B2][B1][B0] >> (0 + 4) = [B7][B6][B5][B4] [B7][B6][B5][B4] & 0x01 = [B4] [B4] is then written to the LCD. i=1) [B7][B6][B5][B4][B3][B2][B1][B0] >> (0 + 1) = [B7][B6][B5] [B7][B6][B5] & 0x01 = [B5] and so on until i = 3, where all data has been sent.

Hey, it's me again, this time with some interesting questions: I have been working with a Hitachi HD44780-based LCD and as part of my project I am writing an extended library to perform read operations from the screen.

He adds that the availability of the code makes it easier for developers to seek support because they can be more specific when reporting their problems.

I tried sending a pulse to the strobe (enable) to get the next bit, but that caused undesired side effects, like text randomly disappearing from the screen, which leads me to believe that approach is wrong.

Basically, the same way it's sent into the HD44780, 4 bits at a time. there will be two operations for every 8 bits, because its passed 4 bits at a time.

cm" and would display the warning whenever the case. Reverting the library to its previous state fixed the problem. In case you are wondering, the distance was obtained from a PING sensor. I'll add proper timing and initialization to the library and we'll see what happens afterwards.

Now I have something I can work with. I don't do much C programming but I am pretty sure I can follow what you have given me.

Since the LCD has only 8 data channels, an 8 bit integer (char type) is enough to hold the data. This is the same implementation I had written a while back and that fails (corrupts the LCD screen display).

Excuse the ol' scepticism, but if you have an LCD connected to the arduino that has data on it you need to read, surely that information came from the arduino in the first place. Wouldn't it be a lot easier to fire up another variable to hold the data for the next time rather than pulling it back from the display ?

So far I have not really studied your code but from what I have said before it appears that somewhere when you think you are 'reading' from the LCD you are actually 'writing' to it. For that reason it may be beneficial for me to look at lcd_sendRaw() so that I can compare it to lcd_getRaw().

Keeping in mind the fact that I do not use the Arduino sketch editor (too crummy for me to work on) and that I code directly in C using some of the wiring extensions.

Part of the way a games company can live on is through the titles and technology it creates, but for those to last, they need to be shared.

"If you look at the macro trends in software, generally code that is open and shared has a higher chance to be robust over a period of time," he says. "Linux is a great example; [that] has basically taken over the operating system business because when it's open, anyone can contribute, extend, fix, and enhance, and the longevity probabilities are much higher.

Check out the 'Comments on Commenting' at Comments on Commenting. In the 'Commenting Suggestions' at the end he states "My standard for commenting is that someone versed in the functionality of the product - but not the software - should be able to follow the program flow by reading the comments without reference to the code itself."

Algorithm to obtain raw data We can store all data that is read from the LCD in one byte (8 bits). This will be stored in an 8 bit integer (same as a char type). For ease of access, we use an 8bit unsigned integer as defined in . Unsigned 8 bit integers range from dec0 to dec255, or b00000000 to b11111111.

"I would say, in many ways, not a lot," he laughs. "This is obviously people themselves doing it. But we often think: are we creating a playground, a theme park, or a sandbox?"

Yeah, DDRAM must be getting corrupted somewhere. What I don't understand is how is something that was written to the LCD disappear and the rest of the stuff still be around. It's not like random characters came up or anything... The LCD was supposed to show "Distance:

At the heart of the Carbon Development Platform is the Carbon Engine, which powers Eve Online. With this soon to be released to the world, what does Pétursson expect or hope to see? Could developers or even tech-savvy fans use it to build a new Eve, or is it more likely to be used to build something completely different?

As with any instance of a company sharing its technology, our first question when we catch up with CCP CEO Hilmar Veigar Pétursson is why. For Pétursson, it comes down to legacy.

What is missing from your code, as far as I can tell, is proper implementation of at least some of the timing requirements. For example look at the Enable pulse width which must be at least 150 nS wide according to some datasheets but must be as long as 450 nS on others. In assembly language (and maybe in very efficient C) pulsing the enable pin high then low can be done with two 2-cycle instructions which takes 270 nS at 16 MHz. Therefore this may work all of the time on some displays, some of the time on all displays, etc. but not necessarily all of the time on all displays.