Well it would certainly be a nice amount of exposure :-)
Well it would certainly be a nice amount of exposure :-)
:: AthenaOfDelphi :: My Blog :: My Software ::
On competitions:
I personally don't like competitions. Always seems like a waste of time to me. Like I'm trying to prove something that I don't have to prove
About game engine:
1.
One can use Pascal to make games. Do you really want to prove it? What for? I personally don't feel like proving anything. There are games written in Pascal. What other proof one could possibly want.I want to try and help the rise and start showing all those nay sayers who believe you can't use Pascal to make games that they are quite frankly wrong
The reason why Pascal is not widely used is not because one can't create games with Pascal.
2.
There are fewer and fewer developers who use Pascal. This is a problem. Not only this, but the development as we know it might soon cease to exist due to ever increasing pace of technological progress.
I am an experienced game developer, I probably could develop a game engine.... given infinite time.
What if most people stop using PC soon?
What if most people stop using Windows soon?
What if programming skills will be no longer needed soon?
3.
Like the author of the first post said, there are already game engines. So why create another one?
Commercial game developers can use commercial game engines like Unreal Engine. Hobbyists can use hobbyists game engines including existing game engines for Pascal.
Well, I am starting to feel that I produced too much text by now and I should stop this soon......
ACTUALLY I think that it's great idea but.... but..... at the same time it's difficult and pointless. Well, I don't know. Who is going to develop it? Who is going to test it? Who is going to use it? Too many questions
---
@Andru: what if I told you that you're doing it wrong? Don't use [0..0] arrays. Don't use debugger. Make ur engine more object-oriented; right now it looks much like it's written in C.
Sometimes competing in a competition can provide the impetus to actually start something and more importantly, complete it. They aren't for everyone, but certainly based on the success of events such as Ludum Dare, and even some of our competitions, they are very popular. Plus, they can serve as a proving ground for game ideas and concepts.
As for the engine...
1/ You are right, there are engines out there, but they are normally one persons solo project. This means they are normally not as well documented as they could be, have a fit for a particular purpose, and people generally seem very reluctant to (a) let go of it and let other people in or (b) offer to help out because normally when people get to hear about it they are well under development. The idea (and this is based on comments and chats with various members here) is to start from the bottom, with many people involved. That way everyone can learn something (this is a key reason to do it) and the pressure isn't on one person to do everything (this can be a big factor and has probably resulted in a number of promising projects ending prematurely). And the proving it can be done comments... well, I'm just passionate about this place. I want to try and demonstrate to the nay sayers that Pascal is a viable choice for developing games and hopefully grow the community. The popularity of Pascal is an issue granted, but I've encountered people who have been ever so surprised when I told them I developed games in Pascal 'Oh, you can do that can youI would have thought you'd use C++ or something like that'. If new developers are coming through and they get hit with that kind of attitude, they may never give Pascal a try out.
2/ There were fewer developers using Pascal. Activity in the job market and on Delphi related sites (Stack Overflows Delphi section for example) suggest that actually the number of people using it is increasing again. With the advent of the cross platform capabilities in XE2, the language is becoming a far more viable choice again. Development as we know it is not going to stop anytime soon, people aren't going to stop using PCs anytime soon and programming skills will always be needed (someone has to write the stuff that allows non-programmers to make things). The most likely scenario you've highlighted is that the popularity of Windows will decline... I hate to say it, but whilst consumers need machines to do things like surf, watch movies, read their email, play games... there are only two real alternatives at the moment... Windows and Mac OSX. Linux, despite massive progress towards being more usable (IMHO at least) still cannot compete with the big two in terms of ease of use.
3/ The author was me and I completely stand by what I've said for the reasons I've highlighted above. Starting one as a community is a great chance for everyone who has ever wanted to do it, or has done it previously but has stopped because of the pressures of being a solo dev on the project etc., to actually do it and say 'I did that', 'I made this game with the engine I helped build'. I don't know about you, but I like that idea... I like it alot and so do alot of other people. They want to do it to be part of a bigger project (one that they probably couldn't fully complete on their own), to have the satisfaction of doing something, and because they'll hopefully get the chance to learn some stuff along the way.
Who's going to develop it? We are. Who's going to test it? Us and anyone who's using it. Who's going to use it? Us and anyone who wants to.
:: AthenaOfDelphi :: My Blog :: My Software ::
@dj_sharp
This is just a hack, and I know this. Currently I don't use [0..0] arrays for PByteArray type because of "Range Check Error". And because of this I got problem with debugger(I didn't know about this till I switched to 32-bit version of Lazarus and Windows). Why I use PByteArray? Because dynamic arrays suck. Performance is low and so on. About object oriented - I like plain-style, not because I can't use OOP(at work all my code use classes and so on), just it was more fun for mewhat if I told you that you're doing it wrong? Don't use [0..0] arrays. Don't use debugger. Make ur engine more object-oriented; right now it looks much like it's written in C.
@Andru
I totally agree with you about dynamic arrays. I mean which idiot though about idea that best solution to increase the size of dynamic array is to double it's size?
Imagine this: You have a byte array with 1024 items in it (using 1 KB of memory) and then you add just one item to it and it's size is doubled. Imagine that you have 1GB sized array and you add one new item. Utter stupidity.
Have you ever sonsidered using TMemoryStream?
You would probably want to override the Read/Write mothods so that you won't need to specify current position using before calling them but include the position as aditional parameter. I belive it could be done and it should provide quite good performance.
Idiot you say... Now, i don't know how the arrays actually work, but lets assume like you say that dynamic array doubles it on power of 2 margins.Originally Posted by SilverWarior
Imagine that you have [0..0] pointer array of size 1024 and you increase the size by 1 for 10 times in a row. Dynamic array makes only 1 memory allocation of 2kb, but pointer array makes reservation total over 10kb (1025, 1026...1034)! In addition to that, it's like a puzzle game in the memory - having odd sized memory blocks of random 1023, 1050 etc are harder to organize than if the blocks are evenly sized.
(Oh, what also happens on array resizing, is existing memory copied to new array. Again Setlength() would win by big margin.)
I haven't noticed much of a performance difference at all if you use dynamic arrays vs pointer arrays for texture memory. For most arrays you don't ever need to resize it, and when you do, dynamic arrays might win in performance. Previously i have known that TList follows the memory doubling method, but i am not sure about setlength(). And there are likely some limitations in higher amounts of memory, smaller reservations.
Last edited by User137; 25-04-2014 at 06:50 PM.
As an aside on this note, I'd be very interested in any tests/information anyone has on this. I use a lot of dynamic arrays that seem to behave themselves. My assumption is that its written that way to avoid causing memory fragmentation for memory sizes that scale linearly across all orders of magnitude (ie. there are x allocations done to get from 1KiB to 1MiB and another x allocations to get from 1MiB to 1GiB). I agree it could be better done. The question is what does it understand by 'allocate'? Is it allocating virtual, private or some other 'kind' of memory so that it has the memory needed/mapped/allocated but the OS can use it for other things until the array grows to that size?
I once tried to change the world. But they wouldn't give me the source code. Damned evil cunning.
Ups. I must admit that I have mixed arrays with Lists
Afaik dynamic arrays will only double in size only if you try to resize them. And it's existing size + new size. Resize will allocate new memory, copy over data and free the previous memory. In case the new size is smaller it is possible no reallocation will occur. Does not take up double memory, just the difference between new and old size, with a temporary need for additional memory while the array is reallocated. It does lead to memory fragmentation more easily. Also, the same will happen if you use a pointer to an array, and re-allocate the memory yourself. The same process happens, and dynamic arrays should not be that much slower than manual memory management. With dynamic arrays the compiler manages the memory and there is a small overhead (reference counting and what not). In any case, best to do as little resizing as possible. An idea for a benchmark.
Existence is pain
Competitions are not a waste of time! Main benefits of competitions are:
1. By participating in competitions your are actually advertizing yourself. You are showing your knowledge level to others. This can be especialy benefitial if your are trying to get a job in computer industry.
2. Competitions offer you great opurtunity to test some of your ideas.
3. By participating in competition your would probably be doing something different than you are usually doing. This could provide you with a new perspective. And that new perspective may even help you get better with your primary work.
It is not question wheter if it is posible to make games in pascal. It is question of it is posible to make games in pascal which are of todays standards? And we all know that game standards have changed greatly in the past few years.
That is true. But answer me this. Is there more buisniess application developers or game developers in computer industry?
Answer is that there are more game developers in computer industry than buisniess developers. Game developers are those who drive the whole computer industry.
But if you look at pascal comunity you will realize that the above fact is not true. There are actually more buisniess pascal developers than pascal game developers. And that is sending out the message that pascal is more suited for buisniess application development which then draws away lots of potentional developers due the fact that game development is most popular.
So the main purpose of PGD is to show that pascal is as suitable for game development as it is for buisniess application development as this would atract more pepole into using pascal.
I'm not an expirienced game develoer but given infinite time I could develop a game engine on my own. Heck given an infinite time I could develop a whole OS
Haven't you noticed? Objective Pascal is no longer limited to Windows and PC platforms
I can figure out only two posible scenarios for this to happen:
1. We somehow develop an AI which is capable of reprogramming itself. We are doomed when this happens.
2. A catastrofic event causes all electical devices to stop functioning. We are also doomed in such scenario.
Why do big game development studios develop their own game engines and not use the existing ones?
Becouse no matter which game engine you are using there is a large posibility that sooner or later you will hit the limitation of that game engine. So if you are using some third party game engine you need to contact the original developers and ask them to help you get rid of that limitation or you have to live with that limitation.
But if you are developing the game engine on your own then you can get rid of that limitation on your own.
Being hard it doesent mean it is pointless.
As for those of you suggesting that we simply go and make headers to use most popular game engines like Unity:
While this might seem better solution in the short run it is not necessarily better solution in the log run.
As I have sad above you are limited by the functionality of that game engine. Even worse due to language differences you might be even more limited due to these language differences.
As it is with most third party libraries/components debugging can be a nightmare. You coučld encounter a bug and not know if it is cause by your code or by third party game engine. Now if you have game engine written in Objective Pascal you might convince the author to share the code with you so you can literally debug both your and engine code and thus find the bug wherever it is. But if the game engine is written in another laguage you can forget about this.
So far I haven't heard of any utility that might alow symuntaniosuly debuggin one application whose components are designed with multiple programming languages.
Posting Permissions
Reply With Quote
Bookmarks