PCEngineFans.com - The PC Engine and TurboGrafx-16 Community Forum
Tech and Homebrew => Turbo/PCE Game/Tool Development => Topic started by: RegalSin on January 27, 2012, 05:42:58 AM
-
Why is it not fair?
That is simular to what I was working on. I am working on a shooter, and I have been doing so for many years.
This is all from 2005. First it was an RPG to be made for the SNES, then at some point I decided I wanted to be on the PCE and maybe even MSX version but then I decided to make a prequel animation to the series of events that leads to the rpg, which eventually brings us to the MMORPG grand final. Sometime I decided to make a action game, and comic to the animation. Then I decided on something else more reasonable, a shooter.
What was I doing, all that time? Going to college on and off, working petty unlisted jobs, then of course internet. I am still doing that now.
Then I started to work on the sprites for the game, which I am doing on and off.
Why the PCE? Because I wanted it to be on a system that is respected, but has little or nothing to do with 3d. Also the PCE has little or no changes for over an entire decade asides the DUO systems.
I had originally planned the RPG to be on the Sega Saturn, after seeing the 3d on the Saturn.
That example is exactly what I was planning to make.
An object moving shooting rotating objects, plus paralexx scrolloing, along with a score and live chart. That is perfect. However mine is using bigger looking sprites. I am still attempting to make a big sprite display, along with no bg_color. Next I am going to be working on
creating the hit_console and damage, plus the variations of enemies
on screen.
Then all my work is stuck on a hard drive that I do not even know is working ](*,) ](*,) ](*,) ](*,) ](*,) ](*,) ](*,). I am serious, I powered up my computer one day, and the harddrive started to smoke. I know I have to carry it into an expert with a replacement hard drive parts. It is alot of important stuff.
-
You need a thread of it's own to comment on a post from another thread with no context WHY? #-o ](*,)
-
Sometimes the things called up front for backings (one time forebears intoned backups) via advanced half of sevens or circles of writing. Careful men and women know well this, with planning and forethought to crash and burn avoidances.
-
Dude... First rule of thumb... ALWAYS back shit up. You should know better than this, IF everything you say is true. You always have a backup plan man. Take your drive out, hook it to USB and see if you can salvage anything. Maybe it just wont spin up, or boot Windows.
-
About the game I was working on, most of it is in skull, with all my other ideas but documents, texts, and efforts is on that drive.
I was in the proccess of backing it up. I plugged in another drive to back up this drive, and then the drive I wanted to back up just started to spark, and smoke. It rushed to plug out the computer since it would not turn off. I take out the drive all the time, and have been doing so for many years, I don't know what happen this time?
All I know is where the power supply plugs into the board was glued
to the board, one of the memory was also fried, along with the plug that goes into A drive. I do not understand why that occured???
The only other time when something like that occured was when I had a powermac and computer plugged in to the same outlit, along with the Air Conditioner during the summer. Then everything shut-off and the power supply was smoking.
I tried ordering a replacement board I all I hear is loud sounds. So I am assuming the head acutators, heads, or head reader. It makes a loud noise when trying to do the read. I could still hear the actually platters if I pick up the drive, and move it left or right a bit ( which is normal with all drives ).
I was thinking about going into it but I do not have the tools, the housing, the zero dust control area, or anti-magnentic etc. I want to send it to a place. I have seen a couple on youtube and this one proffessor works in a drive recovery place.
I do not have the cash for that, and thus that, is not going to happen anytime soon. Drive is a Maxtor 120GB.
It has to be a hardware problem, do not mind that, I will get it checked out.
-
That is simular to what I was working on. I am working on a shooter, and I have been doing so for many years.
Cabbage posted WIP's of this game before you showed up here being a retard.
This is all from 2005. First it was an RPG to be made for the SNES, then at some point I decided I wanted to be on the PCE and maybe even MSX version but then I decided to make a prequel animation to the series of events that leads to the rpg, which eventually brings us to the MMORPG grand final. Sometime I decided to make a action game, and comic to the animation. Then I decided on something else more reasonable, a shooter.
Shooters are no more reasonable than an RPG. All of your plans are far too grand anyways. You want things on PCE, MSX, and Saturn, but you can't even get sprites on PCE to work. You're hosed.
What was I doing, all that time? Going to college on and off, working petty unlisted jobs, then of course internet. I am still doing that now.
I wrote Insanity while attending school full time, and working a job. Quit whining.
It's really idiotic that you made a thread saying it isn't fair someone else did some work that is nice. What's not fair is you being an idiot about it.
Stupidity like that is what discourages people from bothering. They present their work and some jackoff like you goes HTTAS NOT FARE, THIS WHAT I WAS DOINGNG.
shut up and do your project, or go away.
-
Shooters are no more reasonable than an RPG.
I would say that HuC is probably better suited for making RPGs than Shmups or other faced-paced action games; that shmup demo I posted suffers from horrible slowdown with another sprite or two thrown on screen. Since RPGs are generally a little slower and less CPU hungry, a nice(simple) engine could be written without too much trickery and inline assembly. The same could be said of a lot of other genres--puzzle games, strategy games, card/board games, adventure, quiz games (who mentioned pcefx.com quizgame?? hehe), etc.
-
When I said it is not fair, I meant it jokingly.
Of course Arkhan. Everybody has to begin with something. It is not that I can't draw an image on screen, I was talking about making a really big sprite on screen, and then using that method over and over again.
You think that is my only idea. I have more ideas, and work on the side as well. More enough to last me for years. That is why I am attempting to program now. I switch from the RPG idea for the obvious reason. Because it would take longer, and is too big to finish with my current standing. I will post that later on.
I would say that HuC is probably better suited for making RPGs than Shmups or other faced-paced action games; that shmup demo I posted suffers from horrible slowdown with another sprite or two thrown on screen.
Well what if it was CD game, would that change the slowdowns?
Look at that Ultimate Muscle ( the game with the two greasy men ).
Yes it has slow downs but does that stop it from being a good game?
No. Where are these slow downs?
One time in the ocean level, a bunch of falling fairy men sprites,
and two muscle fishes pass by, along with the overloading of the
beats from the Venus Muscle. So what, if that game can run, then my game can run.
That shooter example was amazing. It even had rotation. I do not even think I saw any slowdown, asides for the flickering, and who cares sometimes slow-downs makes the game more dramatic.
I will post pictures later on.
-
I would say that HuC is probably better suited for making RPGs than Shmups or other faced-paced action games; that shmup demo I posted suffers from horrible slowdown with another sprite or two thrown on screen. Since RPGs are generally a little slower and less CPU hungry, a nice(simple) engine could be written without too much trickery and inline assembly. The same could be said of a lot of other genres--puzzle games, strategy games, card/board games, adventure, quiz games (who mentioned pcefx.com quizgame?? hehe), etc.
It all comes down to planning and the right mix of assembly language and C code. I prototyped Metro Blaster in pure HuC and it zips along quite nicely with many massive onscreen sprites, though the code required for that speed was very large. If I convert the code-heavy portions to inline assembly, speed will be maintained and the code size will come down dramatically. Monolith maintains a high frame rate and it's mostly HuC; it has some inline assembly provided by Arkhan to boost its performance. Xymati is about half HuC and half assembly. In order to get speed out of pure HuC, you have to avoid the use of arrays... array code is a lot slower than normal variable code, as there's more steps involved and thus more overhead. It really makes a huge difference when you're doing dozens of array accesses every frame. So yes, HuC can certainly be used to make some speedy action games... but you're either going to have to give up array access altogether or replace it with some optimized assembly of your own. One major benefit to using your own assembly code is that you can use the zero page, which HuC code can't normally directly do, which will shave off quite a few cycles over time. Every cycle counts when doing a fast-paced game.
-
In order to get speed out of pure HuC, you have to avoid the use of arrays... array code is a lot slower than normal variable code, as there's more steps involved and thus more overhead. It really makes a huge difference when you're doing dozens of array accesses every frame.
I'm pretty sure this is what caused my slowdown issues :(
-
Planning software is easy and fun. Writing the initial code is generally fun as well. You see lots of results and feel like you are making lots of progress. The hard part is finishing the project. Debugging and polishing a piece of software sucks. You probably don't care that some pixel's out of place. You know not to hit a certain button combination that results in a fatal crash. Facing a Heisenbug (http://en.wikipedia.org/wiki/Heisenbug) really ruins your day (or week). It isn't fun to try to weed out that sort of thing. I suspect this is why most projects are never finished.
-
Quote from: The Old Rover on Today at 01:35:53 PM
In order to get speed out of pure HuC, you have to avoid the use of arrays... array code is a lot slower than normal variable code, as there's more steps involved and thus more overhead. It really makes a huge difference when you're doing dozens of array accesses every frame.
I'm pretty sure this is what caused my slowdown issues Sad
And that's where a little bit of assembler can make a big difference. Especially using the X or Y register for loop indexes, and keeping things in the zp area when you can.
Planning software is easy and fun.
Funny. No plan ever survives contact with the enemy. And no game plan is ever complete :)
Writing the initial code is generally fun as well.
In general, yes. Fixing typos and debugging (what should be) simple things....Not so much :)
Debugging and polishing a piece of software sucks
Big Time. I remember reading once that about 50% of a projects time is spent debugging things.
And you -never- get -all- the bugs out. :(
-
Games go like this:
Step 1) Idea! Sounds easy!
Step 2) Prototype! LOOK ITS LIKE THIS BASICALLY ALMOST DONE
Step 3) GODDAMNIT
Step 4) WHAT THE HELL THAT WORKED BEFORE WHAT HAPPENED
Step 5) f*ck
-
MSR was stuck in step 5 for about 3 years. :D
-
Games go like this:
Step 1) Idea! Sounds easy!
Step 2) Prototype! LOOK ITS LIKE THIS BASICALLY ALMOST DONE
Step 3) GODDAMNIT
Step 4) WHAT THE HELL THAT WORKED BEFORE WHAT HAPPENED
Step 5) f*ck
Eh i'am completely in this plan, mainly in step 3 to 5, with more,more,more f*ck in step 5 .
For step 4 i'am sometimes as with squirrel, like a chicken wich has found a toothpick .
-
Oh, don't forget about Step 6: "ITS FINALLY f*ckING DONE AND I NEVER WANNA SEE THIS SHIT AGAIN" :)
-
About the game I was working on, most of it is in skull, with all my other ideas but documents, texts, and efforts is on that drive.
I was in the proccess of backing it up. I plugged in another drive to back up this drive, and then the drive I wanted to back up just started to spark, and smoke. It rushed to plug out the computer since it would not turn off. I take out the drive all the time, and have been doing so for many years, I don't know what happen this time?
All I know is where the power supply plugs into the board was glued
to the board, one of the memory was also fried, along with the plug that goes into A drive. I do not understand why that occured???
The only other time when something like that occured was when I had a powermac and computer plugged in to the same outlit, along with the Air Conditioner during the summer. Then everything shut-off and the power supply was smoking.
I tried ordering a replacement board I all I hear is loud sounds. So I am assuming the head acutators, heads, or head reader. It makes a loud noise when trying to do the read. I could still hear the actually platters if I pick up the drive, and move it left or right a bit ( which is normal with all drives ).
I was thinking about going into it but I do not have the tools, the housing, the zero dust control area, or anti-magnentic etc. I want to send it to a place. I have seen a couple on youtube and this one proffessor works in a drive recovery place.
I do not have the cash for that, and thus that, is not going to happen anytime soon. Drive is a Maxtor 120GB.
It has to be a hardware problem, do not mind that, I will get it checked out.
You had me at "skull".
-
Big Time. I remember reading once that about 50% of a projects time is spent debugging things.
And you -never- get -all- the bugs out. :(
This certainly goes for editing scripts and video as well. There aren't as many issues as critical as bugs in a program, but it seems like there's always more potential to spruce up certain lines or certain timings.
-
I dunno how many times I have heard a project was canceled because of a hard drive crash. If you are truly serious about a project, go out and spend some money on a decent backup system! Hell, it doesn't even have to be a fancy LTO tape drive, you can still get a decent external drive for around $100 even with the hard drive shortage/price spike these days. As for the drive that had all your info on it, does it even power up? If you can get it to power up, you can get a decent hard disk recovery program like stellar disk recovery and recover your data.
http://www.stellarinfo.com/ If someone glued the power plug into the motherboard, I assume they didn't know what they were doing or it was a store bought pc (don't get me started on the evils of walmart e-machines and their evil alliance with dell). Anyway, thats my 2 cents.
-
You dont even need an external drive really. A decent sized USB stick would do.
-
What if you manually create a linked list? How's the speed on that?
-
What if you manually create a linked list? How's the speed on that?
Theyre so fast atoms split themselves.
-
What if you manually create a linked list? How's the speed on that?
Theyre so fast atoms split themselves.
Wait, really? How does huc implement arrays?! Data structure performance is usually tied to the operations being performed on the data structure. Inserting or deleting an element in an array might be slower than a linked list, but iterating across the elements of an array should be much faster than a linked list because the elements should be adjacent in memory.
Side note: this is actually I question I like to ask prospective job candidates in interviews. My huc experience is pretty limited, but I assure you arrays are faster for element access and iteration than linked lists in just about every language I've used (C, C++, Java, C#, etc).
-
oh I was joking.
Arrays are slow as dick in HuC because they screwed up the implementation.
XOR linked lists are teh fastest though. :)
Arrays SHOULD be awesome, as theyre like the most basic, simplest data structure... but the are f*cked up. I don't use them in code very much, and when I do, I don't access it as an array.
-
oh I was joking.
Arrays are slow as dick in HuC because they screwed up the implementation.
XOR linked lists are teh fastest though. :)
Arrays SHOULD be awesome, as theyre like the most basic, simplest data structure... but the are f*cked up. I don't use them in code very much, and when I do, I don't access it as an array.
:oops: Sorry about that! :D Does this only apply to explictly declared arrays (ie int stuff[5]) or does it even apply if you malloc it and use pointers?
-
Does this only apply to explictly declared arrays (ie int stuff[5]) or does it even apply if you malloc it and use pointers?
Roflmao....You've obviously never used HuC!
[malloc()?? What's that??There's only 8K of Ram. The overhead for a heap/stack would kill things....]
How does huc implement arrays?
As contiguous bytes of memory. Just like most compilers.
The problem is a combination of things:
1) The CPU is byte oriented. Any address updates (ie, offsets) are done via additions. Yes, there are index registers.. But Huc doesn't use them for arrays :(
2) The CPU has -very- limited indirection instructions. You have to have the address in the zero page area, and do the indirection from there.
Which means, accessing array[5] goes something like:
...load low byte of array address.
...save in zp array addresss
...load high byte of array address
...save in zp array address
...load low byte of offset (5)
...add to zp address low
...save zp address low
...load high byte of offset
...add to zp address high (with carry)
...save zp address high
...indirect load of low byte of array entry
... save it where you can use it.
... add 1 to zp address low
... save zp address low
... add 0 to zp address high (with carry)
... save zp address high
... indirect load of high byte of array entry
... save it where you can use it.
There are a few things you can do to speed it up, but it still takes quite a few instructions to do an array access.
And that's not even discussing the screwed up way HuC actually does it :)
When I do things that need arrays in assembler, I split the ints into high/low bytes. That lets me use an index register as the offset (and allows me to reach 256 bytes, not just 128 for ints) from known addresses. Indexed offsets are faster than indirection (which is what HuC uses everywhere an array is involved), and because things are split, I don't have to update the offset register/base address.
.................
And before everyone starts picking on HuC, remember this: HuC is "small C", not a complete C implementation. It's based on code someone wrote for a 1 semester compiler class. And it shows.
I assure you arrays are faster for element access and iteration than linked lists in just about every language I've used
I vaguely remember (a long time ago) writing assembler stuff for a 68xxx processor. It had a very odd syntax for certain operations: ldi [var],reg
That loaded the value at the address given by reg bytes past the address in var. A 2-level offset indirect. -That- made linked lists a breeze, and bloody fast, too :) Shame I we don't see things like that in use anymore :(
-
HAHAHAHAHA pointers in HuC. You're hilarious!!!!!
=3
Basically, you use HuC to prototype out the game quickly with the built-in library and to organize your thoughts/files/entities....then you go in and hand-optimize it all with asm, because the features of C that make C useful vs. ASM, are totally f*cked.
No structs, jacked pointers, arrays that are slower than the losers at the special olympics, and all kinds of other little "what the hell!?"'s that make it suck really bad.