programming noob, hi forums! Advice please!
Moderator: Stef
programming noob, hi forums! Advice please!
Hi guys,
I'm new to the forums.
I am new to programming as well, I have done several projects in VB6 and some very basic fundamentals so far in C .. I just find it so boring.
Any pointers on how I can learn by coding straight away with some samples etc? So while I learn, I am also producing results that I can see/ test via emulator (or on my everdriveMD)
I just find it so boring watching videos on learning C, or even reading about it..
I just want a side scroller, some scrolling background planes, collision detection -possible weapon firing .. just somewhere to start.
I don't mind using coloured blocks until I get some graphics drawn up but some easier to read code that I could modify or learn from would be great...
I'm really finding this overwhelming, but making an 8 or 16bit game is definitely on the bucket list... maybe I could improve it slowly over a few years!
thanks guys
I'm new to the forums.
I am new to programming as well, I have done several projects in VB6 and some very basic fundamentals so far in C .. I just find it so boring.
Any pointers on how I can learn by coding straight away with some samples etc? So while I learn, I am also producing results that I can see/ test via emulator (or on my everdriveMD)
I just find it so boring watching videos on learning C, or even reading about it..
I just want a side scroller, some scrolling background planes, collision detection -possible weapon firing .. just somewhere to start.
I don't mind using coloured blocks until I get some graphics drawn up but some easier to read code that I could modify or learn from would be great...
I'm really finding this overwhelming, but making an 8 or 16bit game is definitely on the bucket list... maybe I could improve it slowly over a few years!
thanks guys
-
- Very interested
- Posts: 3131
- Joined: Thu Nov 30, 2006 9:46 pm
- Location: France - Sevres
- Contact:
Re: programming noob, hi forums! Advice please!
Welcome L1ON37,
SGDK is really made for C (or assembly) programming, if you are more familiar with Basic i strongly recommend you to start with BEX or SecondBasic. They are both powerful tools to development on Megadrive then later eventually you can try to switch to C with SGDK when you will be more familiar with the Megadrive hardware (trying to sort both Megadrive and C programming at same time will be much more difficult).
SGDK is really made for C (or assembly) programming, if you are more familiar with Basic i strongly recommend you to start with BEX or SecondBasic. They are both powerful tools to development on Megadrive then later eventually you can try to switch to C with SGDK when you will be more familiar with the Megadrive hardware (trying to sort both Megadrive and C programming at same time will be much more difficult).
-
- Very interested
- Posts: 484
- Joined: Sat Mar 05, 2011 11:11 pm
- Location: Berlin, Germany
Re: programming noob, hi forums! Advice please!
To be honest if you want to learn to program in C in a 'fun way' consider getting a Game Duino 1 or 2:
http://excamera.com/sphinx/gameduino2/
The MD is, well, a bit dry at first and you will find yourself having to chip away at it for some time.
C is ok for MD work but you really should consider Assembly for full on, fast code.
Cheers.
http://excamera.com/sphinx/gameduino2/
The MD is, well, a bit dry at first and you will find yourself having to chip away at it for some time.
C is ok for MD work but you really should consider Assembly for full on, fast code.
Cheers.
UMDK Fanboy
Re: programming noob, hi forums! Advice please!
Thanks guys...
The VB6 programs were years ago using some books i purchased... it was all windows stuff using the VB framework.
I did first look into bex and found this
https://www.youtube.com/watch?v=1mtcyLY ... 7O&index=4
At least with basic I can look at the source code and it usually makes sense very quickly. C is very daunting.
Any reading I should do/ courses I could follow on youtube before I delve in a bit deeper than having some ascii characters move around the screen and trigger certain actions once they pass a point on the screen? As mentioned I just want some nice side scrollers, graphics at this stage isn't too important.
I'm guessing basic isn't megadrive specific coding and more general? Could I just look up guides on basic game programming?
I will eventually scour the internet for some more info I guess. There are some pretty good games on youtube written in bex i guess.
I am also keeping my eye on this project but this guy does C programming for a living, its all Assembly. I read roller coaster tycoon was written completely in assembly and that it's quite a programming feat!
https://bigevilcorporation.co.uk/
The VB6 programs were years ago using some books i purchased... it was all windows stuff using the VB framework.
I did first look into bex and found this
https://www.youtube.com/watch?v=1mtcyLY ... 7O&index=4
At least with basic I can look at the source code and it usually makes sense very quickly. C is very daunting.
Any reading I should do/ courses I could follow on youtube before I delve in a bit deeper than having some ascii characters move around the screen and trigger certain actions once they pass a point on the screen? As mentioned I just want some nice side scrollers, graphics at this stage isn't too important.
I'm guessing basic isn't megadrive specific coding and more general? Could I just look up guides on basic game programming?
I will eventually scour the internet for some more info I guess. There are some pretty good games on youtube written in bex i guess.
I am also keeping my eye on this project but this guy does C programming for a living, its all Assembly. I read roller coaster tycoon was written completely in assembly and that it's quite a programming feat!
https://bigevilcorporation.co.uk/
Re: programming noob, hi forums! Advice please!
This isn't what you want to hear, but you really should learn C properly before trying to do "the fun parts". You won't get far just modifying someone else's colored block sidescroller.
-
- Very interested
- Posts: 484
- Joined: Sat Mar 05, 2011 11:11 pm
- Location: Berlin, Germany
Re: programming noob, hi forums! Advice please!
You are making me feel old, and he actually writes in C++ which is very commonly found in the Videogames IndustryL10N37 wrote: I am also keeping my eye on this project but this guy does C programming for a living, its all Assembly. I read roller coaster tycoon was written completely in assembly and that it's quite a programming feat!
Just to upset you: something like 98% of ALL Megadrive/Genesis games were written in Assembly - that's nearly ALL of them.
The top and bottom of it is: learn 68K and Z80 Assembly languages.
Also, you really need to learn to program in C before taking on the Megadrive and to be honest you are better off learning to write 68K Assembly on something like an old Macintosh (68K based in the early 90s) with a full toolchain and an OS to play with or the Amiga or atari home computers.
The hardest thing when developing is to maintain momentum and you have to get to grips with the hardware before you can really feel comfortable.
Most people my age in their thirties learned C either in or just after High School and by the time we went to University we had spent some time getting to grips with C. By all means, if you can handle C you can handle most other things I find. A few months ago I had to find something that would allow me to develop a GUI Application and opted to use C# just for the GUI part - it was dead easy to link things up and a far cry from the amount of work you have to do in C. What's more is that if you understand Assembly very little will surprise you when you debug problems with computers.
I would get something like the C Bible and C Unleashed and get a book on Data-Structures in C and writing Algorithms:
https://www.amazon.co.uk/C-Programmers- ... ds=C+bible
https://www.amazon.co.uk/Data-Structure ... structures
https://www.amazon.co.uk/C-Unleashed-Ri ... +unleashed
One thing I can say though is that, at least for me, because I had learned Assembly before I learned C I understood Pointers much better for having done so. I never found that many good explanations in C books about what a Pointer really was when I first started out so, a lot like Latin, Assembly can be a massive benefit
See how you get on with it and set yourself little exercises that you can complete - it is a bit like intellectual weight-lifting if you like
UMDK Fanboy
Re: programming noob, hi forums! Advice please!
TBH, the reason for 98% of them being in asm is that compilers in 1990 sucked. You now have access to the latest gcc, so little reason to write asm unless you hit performance bottlenecks.
-
- Very interested
- Posts: 484
- Joined: Sat Mar 05, 2011 11:11 pm
- Location: Berlin, Germany
Re: programming noob, hi forums! Advice please!
Not at all, the MD is very low end hardware. I cannot for the life of me think that GCC has improved that much for 68K targets since the mid 90s - why would it?cero wrote:TBH, the reason for 98% of them being in asm is that compilers in 1990 sucked. You now have access to the latest gcc, so little reason to write asm unless you hit performance bottlenecks.
I'll bet you $100 I can write tighter code in 68K than you can in C
I am working on a Shmup and I need all the cycles I can get. Are you working on something fairly low end performance wise such as a puzzle game on a single screen?
UMDK Fanboy
-
- Very interested
- Posts: 3131
- Joined: Thu Nov 30, 2006 9:46 pm
- Location: France - Sevres
- Contact:
Re: programming noob, hi forums! Advice please!
Definitely you can already do *a lot* with C. Writing 100% assembly code is imo just a waste of time as only small portions of your code (the bottlenecks) will probably require assembly optimizations. The first step in optimization is the implementation itself (using adapted structures and algos), then you can optimize your C code to help generating better code and in final step if you need more speed you can pass in assembly for the part which require it. But even using the best ASM optimized code compared to good C code you will obtain a gain of 30% up to 100% for best case.
-
- Very interested
- Posts: 484
- Joined: Sat Mar 05, 2011 11:11 pm
- Location: Berlin, Germany
Re: programming noob, hi forums! Advice please!
Edit: there are some good points raised here: https://www.quora.com/Why-did-C-replace ... -mid-1990s
It is kind of worth nothing too that up to the 16-bit machines it was still possible for a human programmer to write better code than a Compiler and that kind of tapered off when pipe-lining took over as the more dominant feature of CPU design. So until about the 68020 it was still possible to "out smart" the Compiler if you were a fairly well experienced Assembler developer. However, you barely stand a chance with the processors going back to the mid 90s onwards. I once worked at a company in Cambridge who bought another company who specialised in writing highly optimised Codecs and they had a real problem most of the time hand rolling the code on the more powerful PPC and ARM processors. It ended up being a sort of "see what the Compiler does then correct if you need to" kind of modus-operandi and it often took a long time for them to get it right. Back in the day on the Amiga/atari/etc. this was not the case.
With GCC, and although there are other C Compilers around for general 68K targets, GCC would be the more actively developed and dominant now, well you have to ask yourself where the need would be to further improve the 68K back-end within GCC? How many new projects have a 68K core and is it really worth it to expend the development effort on improving things for 68K targets? I very much doubt it because I know that over the last 13 years we have seen a lot of work done for the ARM targets and other RISC targets so you could surmise that the future is RISC and the past is very much so CISC - which means the 68K. We should probably look into benchmarks. I tend to see more discussion on the Amiga forums about tools, Compilers and Assemblers to be honest than on here but I can tell you that very few Amiga developers write in C and most write in Assembly - what do they know that Sprites Mind doesn't?
What neither you nor cero have mentioned is that the insight that the Assembly developer has into how the MD hardware functions is what gives them the ability to determine how well things are executing - down to the individual machine cycle. I am quite sure that yuji naka was very aware of machine-cycles and indeed he worked out a suitable design prior to implementation, but then, he was an experienced, professional who had enough low-level experience at the time he wrote Sonic the Hedgehog.
It is also worth nothing that for poorly designed code you will spend more than 50% of your time debugging and hardware related issues will not be as easy to 'see' at the C level but I find, at least, that they stand out in Assembly - we may differ.
We also need to factor in code size: now this boils down to how you appreciate ROM size: in the 90s and 80s memory was costly so you tend to find most MD games used compression schemes often throughout with 'just in time' data being piped out during execution.
Have you worked out how much space you save writing in pure 68K / Z80 compared to writing in pure C? Size of the ROM image is an important factor still but not as much so as it was back when the MD was still releasing commercially.
But I agree, SGDK and C in general are good enough for beginners and people who have no experience of the MD hardware as it gives them a 'first start' fairly quickly but it pales when compared to Assembly on low-end hardware - am in the minority that I count machine cycles? You will never see any div/mul/etc. in my code as it costs way too much but how many of you chaps use that opcode implicitly in your C code?
Cheers,
Minty.
It is kind of worth nothing too that up to the 16-bit machines it was still possible for a human programmer to write better code than a Compiler and that kind of tapered off when pipe-lining took over as the more dominant feature of CPU design. So until about the 68020 it was still possible to "out smart" the Compiler if you were a fairly well experienced Assembler developer. However, you barely stand a chance with the processors going back to the mid 90s onwards. I once worked at a company in Cambridge who bought another company who specialised in writing highly optimised Codecs and they had a real problem most of the time hand rolling the code on the more powerful PPC and ARM processors. It ended up being a sort of "see what the Compiler does then correct if you need to" kind of modus-operandi and it often took a long time for them to get it right. Back in the day on the Amiga/atari/etc. this was not the case.
With GCC, and although there are other C Compilers around for general 68K targets, GCC would be the more actively developed and dominant now, well you have to ask yourself where the need would be to further improve the 68K back-end within GCC? How many new projects have a 68K core and is it really worth it to expend the development effort on improving things for 68K targets? I very much doubt it because I know that over the last 13 years we have seen a lot of work done for the ARM targets and other RISC targets so you could surmise that the future is RISC and the past is very much so CISC - which means the 68K. We should probably look into benchmarks. I tend to see more discussion on the Amiga forums about tools, Compilers and Assemblers to be honest than on here but I can tell you that very few Amiga developers write in C and most write in Assembly - what do they know that Sprites Mind doesn't?
You can but can you do a lot on the MD with C? It boils down to what you are trying to achieve I feel.Stef wrote:Definitely you can already do *a lot* with C.
Well, this again boils down to design: if I design my code in Assembly to carry out certain actions fast then I know that *way* ahead of time and long before it becomes a bottleneck that you may find in your C code later on. I optimise *at the Assembly level* but I have perhaps used 68K and C longer than many of you.Stef wrote: Writing 100% assembly code is imo just a waste of time as only small portions of your code (the bottlenecks) will probably require assembly optimizations.
No, the first step is design correctly and foresee the type of trade offs you are willing to accept early on.Stef wrote: The first step in optimization is the implementation itself (using adapted structures and algos), then you can optimize your C code to help generating better code and in final step if you need more speed you can pass in assembly for the part which require it.
What neither you nor cero have mentioned is that the insight that the Assembly developer has into how the MD hardware functions is what gives them the ability to determine how well things are executing - down to the individual machine cycle. I am quite sure that yuji naka was very aware of machine-cycles and indeed he worked out a suitable design prior to implementation, but then, he was an experienced, professional who had enough low-level experience at the time he wrote Sonic the Hedgehog.
It is also worth nothing that for poorly designed code you will spend more than 50% of your time debugging and hardware related issues will not be as easy to 'see' at the C level but I find, at least, that they stand out in Assembly - we may differ.
Well, when we work at the Assembly level and we work on our design - our solution, we are optimising our code structure and solution for the problem that presents itself. We are aware of what the hardware is doing and we know what we want to achieve and things are pretty much straight-forward when we look at Assembly language. I am not sure how much hardware and low-level work you have done yourself, Stef, but I can tell you that Compilers and even hardware (these days with all the FPGAs and CPLDs and other hybrids around) "lies" and you will hardly ever see that manifest itself at the 'C level'. As such, for performance and design criteria and if you ever need to reverse and commercial code or even a Demo you are better off spending the time learning 68K and Z80 in the MD's case.Stef wrote: But even using the best ASM optimized code compared to good C code you will obtain a gain of 30% up to 100% for best case.
We also need to factor in code size: now this boils down to how you appreciate ROM size: in the 90s and 80s memory was costly so you tend to find most MD games used compression schemes often throughout with 'just in time' data being piped out during execution.
Have you worked out how much space you save writing in pure 68K / Z80 compared to writing in pure C? Size of the ROM image is an important factor still but not as much so as it was back when the MD was still releasing commercially.
But I agree, SGDK and C in general are good enough for beginners and people who have no experience of the MD hardware as it gives them a 'first start' fairly quickly but it pales when compared to Assembly on low-end hardware - am in the minority that I count machine cycles? You will never see any div/mul/etc. in my code as it costs way too much but how many of you chaps use that opcode implicitly in your C code?
Cheers,
Minty.
UMDK Fanboy
Re: programming noob, hi forums! Advice please!
Perhaps not the backend, but certainly the frontend. I'm pretty sure I could get LTO working, for one. It can do transformations that gcc 1 and 2 just dreamed about - clean code and performance at the same time.MintyTheCat wrote:Not at all, the MD is very low end hardware. I cannot for the life of me think that GCC has improved that much for 68K targets since the mid 90s - why would it?
I can also beat the compiler. That's not the issue. It's a waste of time to do everything in asm, when you don't need to.I'll bet you $100 I can write tighter code in 68K than you can in C
For example, say you need to change the game logic slightly - enemy behavior for example. What would be a one-line change and take seconds in C, you now rewrite half of that asm function and it takes an hour. It's simply a waste of programmer resources when that code does not need speed.
I've completed several MD games already, some single-screen, some four-ways scrolling. How long have you been working on this shmup? It will probably be a good game running at 60fps at all times, but I believe you'd have completed it in 1/10 the time by using C for the majority, asm only for performance-requiring parts.I am working on a Shmup and I need all the cycles I can get. Are you working on something fairly low end performance wise such as a puzzle game on a single screen?
It doesn't matter much. The data is much larger than the code, especially music takes space. Using the full 4mb does not increase the cost at all, unlike in 90s when chips were expensive.We also need to factor in code size: now this boils down to how you appreciate ROM size: in the 90s and 80s memory was costly so you tend to find most MD games used compression schemes often throughout with 'just in time' data being piped out during execution.
Have you worked out how much space you save writing in pure 68K / Z80 compared to writing in pure C? Size of the ROM image is an important factor still but not as much so as it was back when the MD was still releasing commercially.
Eh, I'd say I'm very experienced in C (11 years and counting), and also written asm for several platforms. Asm is almost never worth my time, unless absolutely required for performance. I don't particularly care if a function called once per frame uses division - it doesn't matter.But I agree, SGDK and C in general are good enough for beginners and people who have no experience of the MD hardware as it gives them a 'first start' fairly quickly but it pales when compared to Assembly on low-end hardware - am in the minority that I count machine cycles? You will never see any div/mul/etc. in my code as it costs way too much but how many of you chaps use that opcode implicitly in your C code?
Compiler matters a lot. For a game I recently completed on the NES, it was really disappointing how much I had to write asm to keep it at 60fps at all times. 80% of those were because the compiler is bad (cc65), things gcc would not have done. Had there been a good compiler, that game would only have needed one or two critical functions in asm.
-
- Very interested
- Posts: 3131
- Joined: Thu Nov 30, 2006 9:46 pm
- Location: France - Sevres
- Contact:
Re: programming noob, hi forums! Advice please!
^ That ^For example, say you need to change the game logic slightly - enemy behavior for example. What would be a one-line change and take seconds in C, you now rewrite half of that asm function and it takes an hour. It's simply a waste of programmer resources when that code does not need speed.
100% agree with Cero comments... I started to write a long message but i had to leave and in between new replies arrived so i deleted it.
You have your opinion on that point but designing directly some piece of code in assembly is a bad idea unless you know that part will be critical. Again you can do a lot with only C as long the compiler is "good enough" (which is the case of GCC for 68k target).
Also i have done a fairly amount of low level coding and I don't know if you have used assembly and C longer than us but I am programming in C and assembly (on different CPU) since ~20 years so i believe that give me a bit of experience. To be honest i was much more in favor of assembly when i was younger, being certain it always gives a speed advantage (if you look in oldest Gens version you will see almost code was done in x86 assembly) then i realized how it was a bad idea to do everything in assembly code when only 20% really deserved it (much more time to maintain), i even spent sometime in rewriting some part of my assembly code in C !
Well anyway Cero already replied to the different points, for me the point is that 100% assembly is overkill and C is definitely simpler for beginners. What is true is that it's quite important to understand how work the underlying hardware. If you try to develop a game on MD without really understanding how work the system (video, sound units..) then you will fails miserably, but that is another matter not directly connected to the programming language itself for me.
If you want an example of what you can do with 100% C code on MD :
viewtopic.php?f=8&t=1952
Not bad and that is using an old version of SGDK, current version has better implementations and would provide better performance.
-
- Very interested
- Posts: 484
- Joined: Sat Mar 05, 2011 11:11 pm
- Location: Berlin, Germany
Re: programming noob, hi forums! Advice please!
I shall not go through your comments as you have not gone through mine and see now value in repeating myself.
I shall say it boils down to design. If you can write better C code than you can Assembly code, Stef that simply tells me that you have not done enough Assembly.
There may well be a difference in approach too. I work on Shmups and this is a very top-down type design so all this talk to me of needing to change the game logic escapes me and may do in part for the applications that you are working are different to mine. I generate data that my engine consumes; I have behaviour for the enemies and such. I tend to test-bed by code and work out the behaviour and simply pass a different routine to handle it - it is very piece wise and I have not need to drastically alter the game's architecture, but again, this boils down to design.
I can hack things into existence and I do when I want to try something out, but for game code that I plan on using I design it correctly and there by follows a pretty linear set of design steps.
The chief advantage and disadvantage of say SGDK to my mind is that it makes decisions for people that are not optimal for every situation and it turn hides too much detail - which is great for a beginner or someone with not much experience but severely impedes the developer who has a fair idea as to what they wish to achieve.
For reference that SGDK game that you linked Pingouin Bleu is not particularly demanding of the hardware and I did not see any involved effects. I can have a look at the ROM and see if it does anything involved though but I doubt it.
I think we may come from very different worlds - I live in the world of Shmups
I shall say it boils down to design. If you can write better C code than you can Assembly code, Stef that simply tells me that you have not done enough Assembly.
There may well be a difference in approach too. I work on Shmups and this is a very top-down type design so all this talk to me of needing to change the game logic escapes me and may do in part for the applications that you are working are different to mine. I generate data that my engine consumes; I have behaviour for the enemies and such. I tend to test-bed by code and work out the behaviour and simply pass a different routine to handle it - it is very piece wise and I have not need to drastically alter the game's architecture, but again, this boils down to design.
I can hack things into existence and I do when I want to try something out, but for game code that I plan on using I design it correctly and there by follows a pretty linear set of design steps.
The chief advantage and disadvantage of say SGDK to my mind is that it makes decisions for people that are not optimal for every situation and it turn hides too much detail - which is great for a beginner or someone with not much experience but severely impedes the developer who has a fair idea as to what they wish to achieve.
For reference that SGDK game that you linked Pingouin Bleu is not particularly demanding of the hardware and I did not see any involved effects. I can have a look at the ROM and see if it does anything involved though but I doubt it.
I think we may come from very different worlds - I live in the world of Shmups
UMDK Fanboy
-
- Very interested
- Posts: 3131
- Joined: Thu Nov 30, 2006 9:46 pm
- Location: France - Sevres
- Contact:
Re: programming noob, hi forums! Advice please!
Cero already addressed you comments and i just agreed with them so i saw no reason of repeating him.MintyTheCat wrote:I shall not go through your comments as you have not gone through mine and see now value in repeating myself.
But given this :
I really wonder if you actually read my post... I never said that i can write better C code than assembly, of course good assembly code will always perform better than C code but that is not the point, we just said C is good enough for almost case, and when needed, just mix it with assembly.I shall say it boils down to design. If you can write better C code than you can Assembly code, Stef that simply tells me that you have not done enough Assembly.
But even for that kind of development i don't see where is the problem using C, all parts which are not speed critical can be done in C and for sure you will go faster in C then assembly. You can also quickly prototype an idea to see if it works then implement it afterward... in assembly it's much more time consuming to do thatThere may well be a difference in approach too. I work on Shmups and this is a very top-down type design so all this talk to me of needing to change the game logic escapes me and may do in part for the applications that you are working are different to mine. I generate data that my engine consumes; I have behaviour for the enemies and such. I tend to test-bed by code and work out the behaviour and simply pass a different routine to handle it - it is very piece wise and I have not need to drastically alter the game's architecture, but again, this boils down to design.
I can hack things into existence and I do when I want to try something out, but for game code that I plan on using I design it correctly and there by follows a pretty linear set of design steps.
True, but at least i try to let the choice : use low level methods (as VDP_setSprite(..)) for more control and high levels methods (as SPR_xxx) for easier coding. Of course there is a trade off... But the good point of SGDK is that it can also help you in having efficient design, for instance you now have a DMA queue system you don't need to implement yourself and that will be automatically used for VDP upload operations.The chief advantage and disadvantage of say SGDK to my mind is that it makes decisions for people that are not optimal for every situation and it turn hides too much detail - which is great for a beginner or someone with not much experience but severely impedes the developer who has a fair idea as to what they wish to achieve.
Of course it's still a simple game, but it shows you can do a shmups even in pure C...For reference that SGDK game that you linked Pingouin Bleu is not particularly demanding of the hardware and I did not see any involved effects. I can have a look at the ROM and see if it does anything involved though but I doubt it.
And my point here is that saying to consider doing 100% assembly programming to someone who want to start MD coding and has no knowledge in programming nor MD hardware will just kill him :p It's why i even pushed him to BEX first
I hope you take no offense with the discussion, we can all have different point of view :p
-
- Very interested
- Posts: 484
- Joined: Sat Mar 05, 2011 11:11 pm
- Location: Berlin, Germany
Re: programming noob, hi forums! Advice please!
I have read your post. Yes, that is my point: that for 68K code Assembly will out perform C - I think we have perhaps gotten our wires crossed here as we are dealing with cross purposes: you and cero are pointing to ease of modification to code - very important during development, and I am referring to writing 'efficient and as fast as you can get it code' I think we are all three correct but it comes down to what each of us wishes to trade, no worriesStef wrote:Cero already addressed you comments and i just agreed with them so i saw no reason of repeating him.MintyTheCat wrote:I shall not go through your comments as you have not gone through mine and see now value in repeating myself.
But given this :I really wonder if you actually read my post... I never said that i can write better C code than assembly, of course good assembly code will always perform better than C code but that is not the point, we just said C is good enough for almost case, and when needed, just mix it with assembly.I shall say it boils down to design. If you can write better C code than you can Assembly code, Stef that simply tells me that you have not done enough Assembly.
Again, it boils down to where your interests and objectives lie; I am - shall we say a little obsessed with speed and performance so I go directly to Assembly. I have written 68K now for quite some time and for MD stuff I have just gotten quite used to it. However, just to be sure here, I learned 68K way back in the early 90s on an Amiga and it was a good education at the time but I can actually write faster in C myself and given that I work as an Embedded Developer I actually write mostly C for a living but with the Megadrive I take a sort of "as fast and efficient as you can get it" as this matches my goals of writing a decent Shmup. When I first started working with the Megadrive I used SGDK myself but your decisions 'got in my way' and I felt too restricted so I only wrote one Demo using SGDK and then I used it a few times for quick experiments but after that for the last couple of years I have used only Assembly as it is just 'simple' to me and only so many things can happen I find.Stef wrote:But even for that kind of development i don't see where is the problem using C, all parts which are not speed critical can be done in C and for sure you will go faster in C then assembly. You can also quickly prototype an idea to see if it works then implement it afterward... in assembly it's much more time consuming to do thatThere may well be a difference in approach too. I work on Shmups and this is a very top-down type design so all this talk to me of needing to change the game logic escapes me and may do in part for the applications that you are working are different to mine. I generate data that my engine consumes; I have behaviour for the enemies and such. I tend to test-bed by code and work out the behaviour and simply pass a different routine to handle it - it is very piece wise and I have not need to drastically alter the game's architecture, but again, this boils down to design.
I can hack things into existence and I do when I want to try something out, but for game code that I plan on using I design it correctly and there by follows a pretty linear set of design steps.
Yes, I offer a 'lite' version of my Library that excludes the heavier Routines and instead offers only the core Routines.Stef wrote:True, but at least i try to let the choice : use low level methods (as VDP_setSprite(..)) for more control and high levels methods (as SPR_xxx) for easier coding. Of course there is a trade off... But the good point of SGDK is that it can also help you in having efficient design, for instance you now have a DMA queue system you don't need to implement yourself and that will be automatically used for VDP upload operations.The chief advantage and disadvantage of say SGDK to my mind is that it makes decisions for people that are not optimal for every situation and it turn hides too much detail - which is great for a beginner or someone with not much experience but severely impedes the developer who has a fair idea as to what they wish to achieve.
A DMA queue and a good way to manage DMA is one of the first things that a developer has to work out once they have gotten some fundamentals worked out wrt graphic handling and it is actually useful that you added that module as I can that would confuse people who are beginners so well played there.
[/quote]Stef wrote:Of course it's still a simple game, but it shows you can do a shmups even in pure C...For reference that SGDK game that you linked Pingouin Bleu is not particularly demanding of the hardware and I did not see any involved effects. I can have a look at the ROM and see if it does anything involved though but I doubt it.
And my point here is that saying to consider doing 100% assembly programming to someone who want to start MD coding and has no knowledge in programming nor MD hardware will just kill him :p It's why i even pushed him to BEX first
I hope you take no offense with the discussion, we can all have different point of view :p
Stef, we can do anything in C or 68K IFF we wanted to
Yes, I agree, the original poster was asking about learning C and I linked some books and ideas and even some easier Gaming hardware to learn on - the Game Duino (which is actually pretty good and you can do a lot with it) to get him started.
No offence taken what so ever, Stef and cero. I think some times it is easy for people to get the wrong idea on forums and we all 'see' things from our own experience and what we feel is relevant to our own situation - I am pretty much ONLY interested in Shmups you see and I have never really considered other genres whereas other people may well be looking at several genres so no worries at all and thanks.
Cheers,
Minty.
UMDK Fanboy