small 2D shooter with some impressive effects

[Blankname]

Anyone have source to this (sorry for such old bump), but the source link is dead and it may have some info I need for a current project.

[Demivec]

Anyone have source to this (sorry for such old bump), but the source link is dead and it may have some info I need for a current project.

Here's a temporary link to it. I'll modify this message in 2 weeks and remove the link. Get it while you can.

[Blankname]

Anyone have source to this (sorry for such old bump), but the source link is dead and it may have some info I need for a current project./quote]

Here's a temporary link to it. I'll modify this message in 2 weeks and remove the link. Get it while you can.

Very nice thanks! has more info that I am learning from than I expected.

[Zach]

Wow... This thread is epic

[mp303]

Epic Fail, more like

The source is still available here.

And yes, I'm still here, haha

I just dropped by to see if PureBasic was still happening - many years later, and still no OOP, so I guess that's pretty definitive.

I have worked with numerous other programming languages over the years, and I have just one new thing to bring to the table - take it or leave it.

As I have argued in the past, you have objects in PB: Structures are essentially objects without methods. My view on that has not changed.

As we also debated in the past, the concept of object-oriented programming is applicable to any language, including PB - it just isn't very practical (and the resulting code not very maintainable) without any native syntax to support it. I stand by that as well.

I did not know much about pure functional languages back when this discussion started - I took an interested in purely functional languages when they started having a renaissance these past years, and some exciting new functional languages popped up in the landscape, and quickly noticed some key differences between these languages and what I had heard described in the past as "functional" languages.

PureBasic is not a pure functional language.

Now, before flames start coming out of your eyes again, let's get our terminology straight here

PB relies on mutable state, in the form of mutable variables. By definition, that makes it an imperative language - an altogether different family of languages from functional languages.

Most object oriented languages are imperative, so PureBasic belongs to the same family as most mainstream OO languages - and not to the family of pure functional languages. PureBasic may be "pure something", but purely functional, it is not.

In my opinion, any imperative program by definition is going to contain some aspects of object orientation, because what is object orientation really, at a fundamental level, if not a conceptual model to help encapsulate and manage state? Of course in actual language implementations, it's more than that, but the OO concept is truly just a mental model.

Well, you have mutable variables and Structures and you manage their state, so you're using OO concepts already - with or without keywords such as "Object" appearing in your source-code. You even have Interfaces in PB now, which means you have inheritance - a classic object-oriented concept.

One practice I have learned and embraced over the years, while doing web-development, is that of pure models and service-oriented architecture - essentially, using classes with no (or few) actual methods to model the business domain. The actual methods go into separate classes (called "services") which have no (or little) state. Ironically, this gives you (almost, not quite) the same kind of separation you are forced to have in imperative non-OO languages such as PB.

Our worlds, then, are not really very different from each other at all. We both have to manage the state of variables and records. We both practice separation of state from functionality.

To summarize: in OO land, we use model-classes, in PB land we use records (Structures). In OO land, we use service-classes, in PB land we use functions. (and recently namespaces, aka Modules.)

It may surprise you then, that I am not here to make another attempt at selling you on the idea of OO in PB.

Instead, I would like to introduce you to C# Extension Methods.

Ignore for a moment the fact that C# is an object-oriented language, and forget for a minute that extension methods in C# also happen to work with classes.

What should make you curious, is the fact that extension methods also work with structs, which are mutable records - the equivalent of Structures in PB. (and they also work with Interfaces.)

Extension methods are static methods, or in other words - an abstract class (containing only static extension methods) is the equivalent of a namespace (a Module in PB), and the extension methods are the equivalent of functions in a namespace. In C#, they happen to be defined using the class keyword, but an abstract class that contains only static extension methods is not a class you can use to construct objects - in other words, it has nothing to do with object orientation per se.

Calls to extension methods may look like class method-calls, but this is in fact just syntactic sugar for static method-calls.

The beauty of this, is that you can avoid redundant repeated references, in your source-code, to the container (class, namespace or Module) where a collection of static methods happens to be defined.

In other words,

Code: Select all

particle.move(0.5, 1.8)

actually literally means

Code: Select all

ParticleOperations.move(particle, 0.5, 1.8)

and compiles to the exact same code. The compiler just has to do a little extra work at compile-time to locate an included compatible move-function.

You can avoid repeating the name ParticleOperations in your source-code, in every function-call - and instead just import it once, at the top of the file. Another recent language from Google called Go uses this approach and perhaps more correctly actually literally calls them "method sets".

It is slightly more work for the compiler to resolve the function-call at compile-time, but there is no run-time penalty - no memory overhead from maintaining method-tables, and no computational overhead from resolving function-names.

So effectively, extension methods remove the need to restate your assumptions with every function-call - they make the source-code simpler and easier to read by removing a lot of duplicate semantics, and in turn this makes the source-code easier to maintain.

Never mind what the syntax would look like, for now, that's besides the point.

If you could have those benefits, without introducing the Object or Class keywords, constructors, destructors, or any number of more complicated OO concepts that seem to make some people break out in hives - would you be interested or more open to that?

Or is there perhaps already an equivalent feature in PB by now that I missed?

Or were you hoping I was dead, and currently wishing I would never come back?

[skywalk]

As I have argued in the past, you have objects in PB: Structures are essentially objects without methods. My view on that has not changed.
~
Or is there perhaps already an equivalent feature in PB by now that I missed?

With Prototypes in your Structures, you get methods

[heartbone]

Our worlds, then, are not really very different from each other at all. We both have to manage the state of variables and records. We both practice separation of state from functionality.

Exactly.

It's just that you have been trained and are used to accomplishing those things a certain (OO) way.
We procedural programmers use other (cheaper in many important ways) philosophies for program design and implementation.

This is the classic computer "scientist" type (you) versus the engineer "hacker" type (me) tussle that must have happened
within many software development groups throughout the decades.

After being exposed to FORTRAN programming while studying Electrical Engineering in the seventies,
in the early 1980s I got into the power of 6502 microprocessor assembly language programming.
Yes I loved those those familiar and limited set of OP CODES, a great improvement over earlier programming methods.
http://6502.org/tutorials/6502opcodes.html
Of course you really needed to know the memory map of the computer that you were working on.
http://www.atariarchives.org/mapping/memorymap.php
We all had to crawl before we could walk,

My initial exposure to object oriented was in the late eighties when it really sucked, and as a result I hated it.
I know that it's a lot better now, but after it's all said and done it still all compiles to the machine code.

So use whatever works for you.
If you know of a better programming environment for you than PureBasic, I appreciate the sharing thought.
Perhaps thirty years ago before I knew better... but no thanks, it won't work for me now.
Too many procedures and functions in my toolkit.

Now, before flames start coming out of your eyes again, let's get our terminology straight here

PB relies on mutable state, in the form of mutable variables. By definition, that makes it an imperative language - an altogether different family of languages from functional languages.

Most object oriented languages are imperative, so PureBasic belongs to the same family as most mainstream OO languages - and not to the family of pure functional languages. PureBasic may be "pure something", but purely functional, it is not.

Yep, I'm betting that you have to have a computer "science" degree, right?

According to http://en.wikipedia.org/wiki/Purebasic
PureBasic is a procedural language. I agree.

According to http://en.wikipedia.org/wiki/Imperative ... rogramming

Imperative, procedural, and declarative programming

Procedural programming is imperative programming in which the program is built from one or more procedures (also known as subroutines or functions). The terms are often used as synonyms, but the use of procedures has a dramatic effect on how imperative programs appear and how they are constructed. Heavily procedural programming, in which state changes are localized to procedures or restricted to explicit arguments and returns from procedures, is known as structured programming. From the 1960s onwards, structured programming and modular programming in general have been promoted as techniques to improve the maintainability and overall quality of imperative programs. Object-oriented programming extends this approach.

According to http://en.wikipedia.org/wiki/Functional_programming
http://en.wikipedia.org/wiki/Category:F ... _languages
PureBasic is not a functional language. I agree.

To summarize: in OO land, we use model-classes, in PB land we use records (Structures).

As stated that's a bad assumption. Let me assure you that I don't.
As stated on the Wikipedia page above, Object oriented programming builds on structured programming.
You must know that OO requires procedural thinking to create the classes.
However procedural programming does not require any OO thinking at all.
So why should we go there?
Structured programming predates OO programming by a long time, and with luck will outlast it.

As you should know, the ultimate goal of the OO effort is to make developing software into a SEUCK* style experience.
If that pipe dream ever happened, then there would be nothing to distinguish applications.

Finally I think that you have introduced a bit of a RED HERRING into this discussion
with your ranting about PureBasic not being a functional language.
From what I can see, no one in this thread ever made that assertion.
Maybe you got confused between functional and procedural?
Not being a computer "scientist".... (such a misnomer,
as an Electrical Engineer I am much closer to being a computer scientist than the software geeks who use that moniker.)
not being a computer "scientist".... I just learned something new from the terminology that you just threw out there mp303,
but what I learned from those Wiki pages really isn't important. Just flip the damn switches using the excellent tools that you have.
I am sure that if you can imagine it, then you can accomplish it with PB/assembly.

* http://en.wikipedia.org/wiki/SEUCK

[mp303]

All good.

I do have a degree, not exactly in computer science, but (hard to translate) something along the lines of "systems engineer" - before that I specialized in micro-electronics in technical college, so I learned everything from the bottom up... transistors, micro-processors, computers, machine code, assembler, C, imperative and OO languages, parser and compiler theory, databases, and the classical (waterfall) software development cycle of analysis, design, specification, implementation, etc. - I too spent my young years hacking out machine code on a Commodore 64, so shoot'em-up construction kit definitely brings back memories

But I got into software and web development, where traditionally, no one wants to pay you to write low-level optimizations - clients have high-level business goals that need to be accomplished with fewer lines of code, in less time. It's very different from game development, which even now tends to go in the same direction, with frameworks like Unity3D making complex game code really simple, and yes, of course, at the cost of performance, but even that is usually an acceptable trade-off in "big games" industry, where much more time is usually invested in content creation and design than in actual game code. Of course there is highly optimized assembler and C code underneath the hood of those engines, but the engines and the actual games now are typically developed by very different teams.

Different tools for different jobs

Anyhow.

With regards to Prototypes in Structures - isn't there a (small) performance penalty for using that, as opposed to flat functions?

Even if there isn't, there is still a penalty in terms of complexity in the source-code, since this forces you to explicitly declare all types of methods, and manually apply them to structures. The result effectively would be the equivalent of a method-table, wouldn't it?

Please review my notes regarding syntactic sugar for function-calls described above - I believe this is further from OO than what you're proposing, and closer to procedural in terms of performance?

And certainly a lot more intuitive to read and write. Even if your primary concern is performance, as explained, this doesn't hurt (run-time) performance and should only slightly impact compiler performance.

[skywalk]

With regards to Prototypes in Structures - isn't there a (small) performance penalty for using that, as opposed to flat functions?
Even if there isn't, there is still a penalty in terms of complexity in the source-code, since this forces you to explicitly declare all types of methods, and manually apply them to structures. The result effectively would be the equivalent of a method-table, wouldn't it?
Please review my notes regarding syntactic sugar for function-calls described above - I believe this is further from OO than what you're proposing, and closer to procedural in terms of performance?
And certainly a lot more intuitive to read and write. Even if your primary concern is performance, as explained, this doesn't hurt (run-time) performance and should only slightly impact compiler performance.

My degree is not in computer science either, but in general, I don't apply OO techniques where speed is of concern. But, with Prototypes in Structures, you can create a tightly packaged object without much overhead(No Interfaces/DataSection VTables/AllocateMemory/FreeMemory) and still carry a high degree of readability. Moreso than "flat function" calls. I don't see the worry of the extra pointers to manage and referencing them later when/if multiple copies of the object/structure are deployed. Certainly, a heavy structure(contains prototypes) can be abused if you are constantly creating objects within a tight loop just to access 1 or 2 functions/methods from that object.

[mp303]

Well, particles are a good example, because they are typically simple structures needed in high numbers, with many possible operations - if you're going to manage 10s of thousands of particles, those structures may end up containing more method pointers than actual particle values. With a high frequency of creation/destruction, that means potentially lots of unnecessary CPU overhead from making duplicate copies of pointers.

If all the operations applicable to all particles are distinct, there is no advantage to maintaining all of these copies of what is essentially method-tables - it's hardly justifiable, and potentially cuts performance in half, if scaling to large number of particles is critical.

Something like extension methods could provide the same level of organization with less code, without that overhead.

[em_uk]

mp303 - what is your point?

If you don't like PB, log out of the forums and go somewhere else. This ridiculous debate is basically on the edge of trolling people.

We like PB here and find it capable of producing any number of apps/games. I'm not a VB fan, but do I go to a VB forum and start a sanctimonious debate about why they shouldn't be using it? No, because I have better things to do.

[Kuron]

Any progress on the game?

[link0101]

I've never felt the need for OOP, Sure I've used it. I do html5/javascript programming, so I have to use some of it.

But I stick to functions as much as I can while doing webpage development. I like the fact i can create a function, and call it. thats it. I dont have to create methods, worry about how I link to them or what they also link to.

I can look on the right side of the purebasics IDE and see all my procedure names, call the ones I want and be done with it. I can look down at the bottom of the Purebasic IDE and see a small help line that tells me all the variables a Purebasic command uses and not have to look up the help file if i do not want to, plus the help files are amazingly complete and instructive, and I dont have load up pages of OOP rules so I dont step on any OOP toes.

Plus Purebasic has everything a game programmer could want, Sprites, Sound, 3D, canvas support, Windows , Linux and Mac support. High speed and easy game start-up/set-up, what with calling a window command and drawing something in it. couldnt be easier.

I've been programming since 1982, started out on Atari Basic, moved to the Assembler Editor cart, soon after bought Mac/65, then found a cool cartridge( for my 48k enhanced Atari 400 with a raised keyboard costing me 175 bucks) called Action.

Action mixed basic with some C and I produced a game called Midas Maze with it. and Midas Maze still selling for $19.85 on cart.

My point is not to plug an old game on the Atari 8 bit, of which I am probably the only person here with an Atari 400 still hooked up so I can play Star Raiders the way it was meant to be played, with a keyboard attached to a wedge like computer and a black rubber coated Atari joystick for which i rip off the rubber covering to have better control over my ship.

It is to point out that I, made a full game, with a procedural language (Action), that had zero OOP, and it sold, and still does.

So never use the excuse that a procedural or functional language does not have what it takes to make a full game, cause thats bullshit.

Oh and just to add, look at Blitzbasic, procedural, but yet more shareware games were written in it than any other language, but it doesnt play well with windows 7 now, so I'm sticking with Purebasic!, it now kicks Blitzbasic's ass and leaves a stain.

[mp303]

mp303 - what is your point?

If you don't like PB, log out of the forums and go somewhere else. This ridiculous debate is basically on the edge of trolling people.

We like PB here and find it capable of producing any number of apps/games. I'm not a VB fan, but do I go to a VB forum and start a sanctimonious debate about why they shouldn't be using it? No, because I have better things to do.

Okay, look.

My point? How can you ask that? Look back through the long winded explanations I wrote in the past few posts, actually READ them, and you will see what my point is. I have made a substantial effort to explain my point. Have you made any effort to understand my point, or are you just eager to pass judgment?

If I don't like PB, I can go somewhere else? Wow. If I didn't like it, would I be here for hours, typing, explaining an idea that I believe has the potential to make it more powerful? This is the sort of snobby attitude that drives people away.

I'm the troll? Me? You come in here with NOTHING concrete, making NO effort to understand anything I have to say, dismissing everything I say with a few, short, sly, smart-ass comments, and contributing absolutely NOTHING of substance to what could have been a constructive discussion. But I'm the troll?

Why you shouldn't be using it. I'm sorry, WHAT? I NEVER said or implied that. I'm offering an idea, that's all - and somehow you manage to construe that into some kind of personal attack and an insult to you and the entire community. But I'm the troll?

Trying to get anything across here is a complete and total waste of time - that is the ONLY thing you have made perfectly clear with your posts.

This will officially be my last post on this forum, ever.

I think that's what you wanted, so guess what? You win.

Go bask in the glory, you pompous clown.

Good bye.

[blueznl]

I guess a lock might be in order here...

Anyway, all have some valid points. I personally don't like OO too much, it always confuses me. Then again, I'm old fashoned and not a professional programmer.

On the other hand, I wouldn't mind if (some) OO capabilities were added. What I've seen thus far, I don't think there are any essential issues with a language that would support the procedural as well as object oriented approach.

On the third hand (hmmm... can I borrow your arm? yeah, thanks) one might not be deliberately trolling, but one might be trolling (perhaps even unintentional) nevertheless. What's the purpose of revisiting and making the same point again? Very little.

So all cool down. Leave the trolling to real trolls. And find another kitchen if we don't like the smell of this one.

I guess a lock might be in order here...